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.