Allow setting a different user class for backend users

[elia]

Summary

Solidus has always used a single user model for both storefront customers and
backoffice operators, with access decided purely by roles. One table, one set of
validations, one authentication configuration — so any weakness in customer
signup is a weakness in admin access.

This PR adds Spree.admin_user_class and routes every admin/backoffice lookup
through it, so an application can separate the two. It defaults to
Spree.user_class, so nothing changes until you opt in.

Separating the models buys three things:

• Security — privilege escalation across the boundary stops being possible
  when the two sets of records are siloed.
• Authentication — admins and customers usually want different rules
  (domain-restricted Google signup for admins, magic links for customers,
  stricter password policies). Separate models mean separate Devise scopes.
• Impersonation — impersonating a customer gets much simpler when the two
  authentication systems don't overlap.

What's in here

Spree.admin_user_class is a mattr_accessor alongside Spree.user_class,
with the same String/Symbol-only contract and a admin_user_class_name
counterpart for lazy resolution. It returns Spree.user_class when unset.

Call sites updated to use it: the classic backend (users, orders, search, store
credits, API key controllers, the matching views and the store-credit-events
helper), the users menu item condition, and Solidus Admin (users, orders and
store-credits controllers plus the users/users-and-roles components). The
install generator's initializer template now writes both settings.

Spree::UserClassHandle — the lazy proxy that defers resolving a class name
until runtime, because user models often load before the initializer runs — is
generalized into Spree::ClassProxy, with UserClassHandle and a new
AdminUserClassHandle as thin subclasses. UserClassHandle behaviour is
unchanged.

The :admin_user factory moves out of user_factory.rb, where it was nested
inside :user and therefore always built a Spree.user_class, into its own
file built on AdminUserClassHandle.

New doc at core/docs/admin_user_class.md.

What this deliberately does not do

Setting Spree.admin_user_class changes which model the admin interfaces read
and write. It does not give that model authentication. There is no generator
for a separate admin Devise scope yet, so an application pointing this at a
dedicated model has to wire up admin login itself.

That's the intended next step — a generator rather than a new extension — but
it's out of scope here to keep this reviewable.

Three unrelated test-environment fixes that used to live on this branch have been
extracted to #6532. This PR is now only the feature.

Behaviour changes worth flagging

• create(:admin_user) now builds Spree.admin_user_class. A no-op while
  that falls back to Spree.user_class, but applications configuring a distinct
  admin model will get that model in specs.
• The install generator writes Spree.admin_user_class explicitly, pointing
  it at the same class as Spree.user_class. Generated apps therefore never
  exercise the fallback.
• The users menu item condition now tests Spree.admin_user_class, so the
  Users menu is gated on admin access to the admin user model.
• Admin i18n now resolves against the admin user model. The users index
  breadcrumb, the Users menu label and the email / roles / lifetime-value column
  headers all call model_name.human or human_attribute_name on
  Spree.admin_user_class. Configure a separate AdminUser and those strings
  come from activerecord.models.admin_user and
  activerecord.attributes.admin_user.* instead of the spree/user keys — so a
  dedicated admin model needs its own translations to avoid humanized fallbacks.
  Worth a reviewer's opinion on whether these labels should keep pointing at
  Spree.user_class.
• The users index breadcrumb previously hardcoded Spree::LegacyUser; it now
  follows the configured class, which is a fix in its own right for apps with a
  custom user model.

How to test

Default behaviour is unchanged — the existing suite covers that, since
Spree.admin_user_class resolves to Spree.user_class everywhere.

To exercise the split, point it at a separate model in
config/initializers/spree.rb:

Spree.user_class = 'YourApp::User'
Spree.admin_user_class = 'YourApp::AdminUser'

The admin user index, order customer search, store credits and the Users menu
should all operate on AdminUser, while storefront and checkout continue on
User. Note you'll need to provide admin authentication yourself — see above.

Factory specs:

cd core && bundle exec rspec spec/lib/spree/core/testing_support/

Checklist

Check out our PR guidelines for more details.

The following are mandatory for all PRs:

• I agree that my PR will be published under the same license as Solidus.
• I have written a thorough PR description.
• I have kept my commits small and atomic.
• I have localized any and all user-facing strings that I added to the source code. No new strings are introduced, but see the i18n note above: existing admin labels now resolve against Spree.admin_user_class.
• I have used clear, explanatory commit messages.

The following are not always needed:

• 📑 I have documented new code with YARD.
• ✅ I have added automated tests to cover my changes.
• 🛣️ Guides will need updating once the authentication generator lands.

[codecov]

Codecov Report

❌ Patch coverage is 89.58333% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.13%. Comparing base (ccc5ad8) to head (cae97a3).

Files with missing lines	Patch %	Lines
core/lib/spree/core.rb	55.55%	4 Missing ⚠️
...app/controllers/solidus_admin/orders_controller.rb	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6329      +/-   ##
==========================================
+ Coverage   91.31%   92.13%   +0.82%     
==========================================
  Files         813     1036     +223     
  Lines       17088    21172    +4084     
==========================================
+ Hits        15604    19507    +3903     
- Misses       1484     1665     +181     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jarednorman]

This seems like a good idea to me. This separation could be useful for some marketplace stores we work on as well.

[elia]

@jarednorman wanted to do this for a long time, and never got the time until I was able to delegate 😅
If there's buy in I'll give it some more (compute) time and finish this first iteration, later I think we can introduce to a better default for new apps.

cc @rainerdema @spaghetticode