feat(member): replace can_log_in with derived active? and drop the column

[mroderick]

Summary

Issue #2784. Replace the stored members.can_log_in boolean with a derived Member#active? and drop the column; stop writing can_log_in in the OAuth callback and gate the details redirect on requires_additional_details?.

can_log_in was never a login gate. Its only consumer, requires_additional_details? (app/models/member.rb), gates profile completion after login, and issue #2783 showed the value had degraded into a parity artifact across 116 members. A member is active by having an auth service, so the flag duplicates easily-derived truth — this removes the column and derives it.

Key behaviours:

• New members keep skipping the profile presence/email validations at signup: during member.save! in the callback the just-built auth_service is not yet persisted, so active? (auth_services.exists?) is false; the member becomes active? after save.
• A complete member who links a second provider is no longer bounced to /member/details/edit — they go to referer_or_dashboard_path instead. This closes the unconditional-redirect part of can_log_in is silently toggled off when a member links a second auth service — 115 members affected #2783.
• Migration follows the strong_migrations ignore-then-drop contract (self.ignored_columns += ['can_log_in'] precedes the safety_assured drop). No data repair is needed: the 116 affected members self-correct to active because they have auth services.

Fixes #2784 · Resolves #2783

Base

Rebased onto master. #2780 (OAuth race fix) is merged, so this PR contains only the #2784 work; no longer stacked on the race-fix branch.

Verification

• 51 + 12 RSpec examples pass (member, callback, controller, joining, ToC specs); rubocop clean.
• ce-code-review (correctness, testing, data-migration): no blocking findings. Advisory P3 items applied (validate uniqueness of member #3 active? false-branch model coverage, beauty #4 referer redirect) and recorded; residual risks noted for the destructive-DDL rollback and the session[:referer_path] staleness (pre-existing).

Post-Deploy Monitoring & Validation

• Deployment note: the migration drops members.can_log_in. Per the strong_migrations contract, ship the code containing ignored_columns in the same release as the migration.
• Rollback: remove_column is reversible (re-adds the column) but cannot restore dropped values; treat the column as obsolete (impact nil).
• After deploy, validation window ~1 week. Watch for NoMethodError / undefined-column errors on can_log_in in Rollbar (would indicate old code running against the dropped column — i.e. a missed two-phase deploy).
• Healthy signal: no errors; Member#requires_additional_details? behaves as before for new-signup and second-provider flows.
• No additional runtime monitoring required beyond the above; the change is entirely derive/drop with no new background or scheduled work.

[mroderick]

Closes the account-duplication confusion from the 28 Jul /auth/codebar feedback

This PR resolves the reported issue where an existing member saw the
"Thanks for signing up" flash and the "Almost there..." details page
(with a pre-populated form) the first time they logged in via a new provider —
which read as if a duplicate account had been created.

Why it happened: in AuthServicesController#create's else branch (member
found by email, new auth service built), we unconditionally
redirect_to edit_member_details_path. That page's controller flashes
notifications.signing_up ("Thanks for signing up...") and its view is titled
"Almost there..." (member/details/edit.html.haml). A complete, existing member
hit exactly this path, hence the signup messaging on a returning account.

What this PR changes: the redirect is now gated behind
member.requires_additional_details? (active? && !valid?), so a complete
member who links a second provider goes to referer_or_dashboard_path instead
of being bounced to profile completion — they never see the signup flash or the
"Almost there..." page. (The existing sends a complete member... specs cover
this.) It also drops the can_log_in write entirely, eliminating the
set-vs-toggle bug on that flag.

Follow-up: an incomplete existing member is still sent to the details
page and still gets the "Thanks for signing up" flash, which remains misleading
for a returning account. Tracked in #2788.

[olleolleolle]

Nice.