Persist signup city on the customer record (v1 users/sign_up + migration)

[aaronsmulktis]

Persists the signup city on the customer record, wired through the backend's real registration path.

What this does

• Migration — adds a city string column to spree_users.
• Permits city in Spree::Api::V1::UsersController#user_params — this is the endpoint the app actually serves for registration: POST /api/v1/users/sign_up → Spree::User.new(user_params). Without this, Rails strong-params silently drops user[city].
• Returns city on sign_up, sign_in, and profile responses so it round-trips, plus Swagger docs for the new field.

Why v1 users, not v2 account

The Spree 4.2.5 fork (1instinct/spree@instinct-4.2.5) makes the v2 storefront account resource show-only — there is no POST/PATCH /api/v2/storefront/account. This app's real user create/auth lives in the custom Spree::Api::V1::UsersController (sign_up/sign_in/profile/follow), so that's where city has to be permitted. (first_name/last_name are derived from bill_address in this model; city is a plain user column, matching the free-text city the wizard collects.)

⚠️ Needs reconciliation for end-to-end

The frontend (Beeper-Frontend) registers via the @spree/storefront-api-v2-sdk — spreeClient.account.create → POST /api/v2/storefront/account (JSONAPI). This backend doesn't serve that route (404) and speaks a custom {response_code, response_message, response_data} envelope on v1, not JSONAPI. So the two repos don't line up on the auth path yet. This PR enables city on the v1 path that exists today; the frontend↔backend dialect needs a decision before signup (and therefore city) flows end-to-end. Options in the issue thread.

Verification

• ruby -c clean on both files.
• Not booted end-to-end: the instinct-4.2.5 fork gems aren't checked out yet locally (bundle install pending), so no migrate/request-spec run. Traced against the actual fork source (routes, controllers, PermittedAttributes) + this app's UsersController.

Base intentionally @aaron.smulktis/develop (the active 4.2 branch). Migration is additive/reversible.