Backend: POST /api/user/change-email/request never verifies the password iOS sends

[Adron]

Found by the payload-key sweep required by #46 (see PR #75).

What was found

ChangeEmailView asks for the account password to confirm an email change, and
APIClient.requestEmailChange(newEmail:password:) (Services/APIClient.swift:148-152) sends
{ newEmail, password }.

app/api/user/change-email/request/route.ts reads only newEmail (:50-51). password,
bcrypt and compare appear nowhere in the file. The password is accepted and dropped.

Why it matters

This is not data loss — nothing is lost — but the iOS UI implies a re-authentication step that does
not happen. Anyone holding a live session or Bearer token can start an email change without proving
they know the password, while the UI states otherwise. Email change is an account-recovery-adjacent
action, so the check being cosmetic is worth a decision rather than an accident.

Ask

Pick one and make the client match:

1. Verify it — compare password against the stored hash before issuing the change token, and
   401/403 on mismatch. iOS needs no change.
2. Drop it — if the confirmation link to the new address is considered sufficient, remove the
   password field from ChangeEmailView and stop sending it, so the UI stops implying a check that
   isn't there.

Acceptance criteria

• Either a wrong password is rejected by the route, or iOS no longer asks for one.
• Backend test covering the chosen behaviour.

Files: backend app/api/user/change-email/request/route.ts; iOS
Services/APIClient.swift:148, Views/ChangeEmailView.swift.

[Adron]

Not implementable from this repo — needs a decision, and the change lands in the backend

Re-verified today against ~/Codez/interlinedlist:

• app/api/user/change-email/request/route.ts:50-51 reads only newEmail.
• grep -nE 'password|bcrypt|compare' over that file returns nothing — there is no comparison
  against the stored hash anywhere in the handler.
• iOS collects the password (Views/ChangeEmailView.swift) and sends it
  (APIClient.requestEmailChange, Services/APIClient.swift:148-152); it is accepted and dropped.

Nothing is lost — this is not data loss like #46 — but the UI states a check that does not happen.

Why I'm not just implementing it

The fix is a security-behaviour change in a different repository, and the two reasonable options
lead to opposite client changes:

Option A — verify it. Compare password against the stored hash before issuing the change
token; 401/403 on mismatch. iOS needs no change; the UI becomes truthful.
Open sub-questions: is the account's password guaranteed present for OAuth-only accounts (GitHub
/ LinkedIn / Twitter / Mastodon / Bluesky sign-up)? If such an account has no password hash, option A
locks them out of email changes unless there is a fallback branch. That needs checking before it can
be written — it is the reason I stopped rather than pushing a patch.

Option B — drop it. If the confirmation link sent to the new address is considered sufficient
proof, remove the password field from ChangeEmailView and stop sending it. That is an iOS change I
can do immediately, and it makes the UI honest in the other direction.

What we need

1. A or B?
2. If A: what should happen for accounts with no password hash (OAuth-only signups)?
3. If A: should this also apply to the other sensitive flows, or is email change the only one
   claiming re-auth it doesn't do? (Worth a sweep — I only checked this route.)

If the answer is B, say so and I'll ship the iOS side today. If A, the work belongs in a
backend PR and this issue should probably move to that repo with the OAuth-account question answered.