feat(integrations): unlink, re-verify and connection health on connected accounts (#40)

[Adron]

Closes #40. Part of epic #38. (OAuth linking itself, #39, remains blocked on redirect URIs.)

Contracts checked before wiring

• DELETE /api/user/identities takes provider as a query parameter
  (?provider=mastodon%3Atechhub.social) — not a body, not a path segment. Confirmed in the spec
  ("name": "provider", "in": "query") and consistent with what :feature:profile already does.
• POST /api/user/identities/verify takes { "provider": "…" } in a JSON body.
• Both success bodies are unspecified (type: object), so they are read as a raw ResponseBody and
  discarded — the refreshed list is the source of truth.

Envelope confirmed live (the agent could not reach the API; I checked afterwards):
GET /api/user/identities → {"identities":[{id, provider, providerUsername, profileUrl, avatarUrl, connectedAt, lastVerifiedAt}]}. So the { "identities": [...] } modelling here is
right, and the published help page's bare-array example is wrong. Also confirmed: provider is
instance-qualified — a real row reads "mastodon:techhub.social".

Staleness threshold: 30 days

/help/cross-posting → Keeping your connections active says platform authorizations expire on
their own, and that LinkedIn's "generally expire after a couple of months and can't be refreshed
automatically". 30 days is half the shortest documented expiry — roughly a month of warning before
the earliest point a cross-post could start silently failing, while staying quiet for anyone who
verifies regularly.

The UI says what it means rather than printing a timestamp:

Last verified 2 months ago. It may have expired — posts may stop reaching LinkedIn without an
error. Tap Verify to check it.

Two design points

• getConnectedAccounts() now merges GET /api/user/identities into the existing per-provider
  /api/auth/<p>/status rows. One identity = one row, so multiple Mastodon instances stay
  distinct — collapsing them into a single "Mastodon" row would have made unlink hit an arbitrary
  instance. (The live account has mastodon:techhub.social, so this is not hypothetical.) A failed
  identities read degrades to status-only rows rather than blanking the screen.
• Neither mutation is optimistic. A failed unlink changes nothing and surfaces the server's
  message; only success triggers a reload.

The unlink confirmation is provider-aware: cross-post targets get "This stops cross-posting to
LinkedIn."; GitHub — not a cross-post target — gets honest wording instead of a claim that is not
true.

Verification

./gradlew :app:assembleDebug testDebugUnitTest → BUILD SUCCESSFUL, 1069 tests repo-wide, 0
failures. :feature:integrations went from 26 to 66 tests. 4 Compose tests compile, not executed
(no emulator).

Mutation-checked, since everything passed first try: widening STALE_AFTER to 90 days fails 5
tests (the three-state and boundary assertions); adding a reload() to the failure branch fails the
two "failed unlink/verify leaves the row untouched" tests. Both reverted.

No :app change was needed — ConnectedAccountsRoute(onBack)'s signature is unchanged.

Remaining risk

The verify response body is ignored. If the server can return 200 with something like
{"verified": false} rather than a 4xx, a failed verification would read as success until the
refreshed lastVerifiedAt contradicts it. I did not call POST /api/user/identities/verify live to
settle this, since it mutates lastVerifiedAt on your real linked accounts.

Also noted, out of scope: :feature:profile has its own connected-accounts screen with overlapping
unlink logic. Deduplicating the two is a reasonable future issue.