test: replace allow_any_instance_of login stub with real OmniAuth login

[mroderick]

Problem

The RSpec/AnyInstance todo entry existed because the login test helper stubbed current_user with allow_any_instance_of(ApplicationController). This PR replaces the stub with a real OmniAuth login in feature specs (controller specs get a lightweight prepend-based stub instead) and fixes a latent bug the stub had been hiding.

Split out from #2768's original four-commit branch; independent of the Lint/Debugger and Naming/PredicatePrefix PRs.

What the stub was masking

Switching to a real login surfaced three failures in specs that only ever passed because of the stub:

1. Double login didn't switch users. A second login in the same test hit AuthServicesController's logged_in? branch and silently kept the old session, while the stub had simply replaced current_user. The helper now visits /logout first.
2. Time stubs expired the session cookie. _planner_session is configured with expire_after: 24.hours, so any spec that stubs Time.now beyond that horizon loses the session mid-test — rack-test drops the "expired" cookie. The affected shared example now logs in again after stubbing.
3. member_joining_spec passed via stale-error leakage. The stub made the controller reuse the test's own Member object, including validation errors left over from the test's own (silently failing) member.update(can_log_in: true). With a fresh record loaded from the session, the spec exposed a genuine bug: Member::DetailsController#update returns early when the how_you_found_us selection is invalid, so members only ever saw that one error and had to resubmit to discover the remaining blank fields.

Changes

• spec/support/helpers/login_helpers.rb — real OmniAuth login for feature specs, LoginStub module prepended onto ApplicationController for controller specs, log out before logging in
• spec/support/shared_examples/behaves_like_managing_workshop_attendance.rb — re-login after the Time.now stub
• spec/features/member_joining_spec.rb — use toggle! so can_log_in actually persists (the previous update failed validation silently)
• app/controllers/member/details_controller.rb — on an invalid how_you_found_us selection, assign attributes and run validations before rendering so all errors show at once

[olleolleolle]

Do we want to "Flip true to false or false to true and save"? OR, directly set the value to a fixed one?

The ! is good, and update! is a thing, too.

[mroderick]

Thanks, good catch — you are right that toggle! was leaning on the false DB default rather than stating intent.

I briefly considered update!, but it would actually raise here: setting can_log_in to true triggers the if: :can_log_in? presence validations, and the Fabricate'd member has those fields blank (which is exactly why the original update(can_log_in: true) was silently failing — it returned false instead of raising).

So I went with update_attribute(:can_log_in, true) — it sets the value explicitly to true and saves without running validations, which matches the intent. Fixup commit is pushed.

[olleolleolle]

Minor: There exists a cattr_accessor. Blog post with interesting notes.

[mroderick]

Neat. Thank you for the link to the blog post, that helped me understand it!

I posted a fixup commit

[olleolleolle]

Super-nice to use the real thing in tests, for this.

[mroderick]

@olleolleolle, I've addressed both comments. Once approved, I'll rebase the fixups away and fix the conflict in .rubocop_todo.yml and we can merge it