Bug: unlinking a connected account always fails — provider sent in the body, route reads the query string

[Adron]

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

Symptom

Settings → Connected accounts → Disconnect (Views/LinkedIdentitiesView.swift:275) always fails.
The route answers 400 {"error":"provider is required"}.

Root cause

APIClient.unlinkIdentity(provider:providerId:) (Services/APIClient.swift:172-175) sends the
provider in a JSON body:

struct Body: Encodable { let provider: String; let providerId: String }
try await deleteCamel("/api/user/identities", body: Body(...))

deleteCamel (Services/APIClientTransport.swift:140-145) sets httpBody and never touches the
query string. But DELETE /api/user/identities
(app/api/user/identities/route.ts:57-60) reads it from the URL:

const { searchParams } = new URL(request.url);
const provider = searchParams.get('provider');
if (!provider) return badRequest('provider is required');

The body is never parsed, so provider is always null.

Fix

• Send the provider as a query parameter: DELETE /api/user/identities?provider=<provider>.
  Percent-encode the value (see the hazard note about .urlQueryAllowed permitting &/=/+).
• providerId is not read by the route at all — drop it from the call, or keep the parameter and
  document that the route unlinks all identities for that provider
  (deleteMany({ userId, provider }), :64-69). Worth confirming that matches the intent: an
  account with two Mastodon identities would lose both.
• Unit test asserting the request URL carries ?provider= and that the body is empty.

Acceptance criteria

• Disconnecting a linked account from iOS succeeds and the row disappears after a refresh.
• Test fails against the current body-based call.

Files: Services/APIClient.swift:172, Views/LinkedIdentitiesView.swift,
InterlinedListTests/APIClientTests/*.

[Adron]

Implemented in #93. Closing here — further work tracks in the PR.

Two corrections to my original write-up, from tracing it properly:

• The disconnect confirmation copy was already provider-scoped ("You'll no longer be able to sign in with GitHub"), so the deleteMany({ userId, provider }) behaviour does not contradict the UI and no copy changed.
• My "an account with two Mastodon identities would lose both" concern was wrong. Mastodon rows are stored as mastodon:{instance}, so two instances are two different provider values and only the matching one is deleted. The multi-row case only arises for rows sharing an identical provider string.