Disconnect: treat a 404 on the provider deletes as already removed

[TheGreatAxios]

Fixes CL-7127 — https://linear.app/abklabs/issue/CL-7127

Problem

disconnectConnector (packages/connections/src/routes.ts:89-153) lists the tenant's catalog providers, issues DELETE /catalog/providers/:id, and throws unless the status is exactly 204 (:116-120), with a mirror check for the credential provider delete (:146-150). The hub's model-provider DELETE answers 404 when the row is already gone, so a second or concurrent disconnect throws and the route (:579-591) collapses that into a 500 "Couldn't disconnect — try again," even though the connector ends up disconnected.

Change

• Treat a 404 from either DELETE /catalog/providers/:id or DELETE /providers/:id as "already removed" instead of throwing; only a genuinely unexpected status still fails the disconnect.
• The route's catch block now reports the failure through reportError from @corbits/error-sink so a real disconnect failure carries a refId and the upstream cause, not just a log line.

Tests

• packages/connections/src/routes.test.ts: two new cases in the disconnectConnector describe block — a 404 on the catalog-provider DELETE, and a 404 on the provider DELETE — both now resolve instead of throwing (previously reproduced the bug and failed).
• bun test packages/connections/src/routes.test.ts: 39 pass, 0 fail.
• cd packages/connections && bunx tsc --noEmit -p .: clean.

[TheGreatAxios]

critique · comment

disconnectConnector no longer throws on hub DELETE 404.

• A provider-row 404 can still surface as HTTP 404 to settings-ui ("Couldn't disconnect — try again.").
• Hugging Face stolen-state 5s timeout is not this diff (packages/onboarding/test/huggingface-connect-routes.test.ts against https://bench.example.com).

Walking-skeleton red on this PR is main deleting DATABASE_URL after memory-mount tests (CL-7182 / #465).

[TheGreatAxios]

critique · comment

API 404-on-already-removed path is covered by routes.test.ts. CI is green.

Live agent-browser on main-gate (not this branch) with local Ollama: Disconnect confirm did not show "Couldn't disconnect — try again." Ollama stayed CONNECTED; fallback still Inherited. That is operator/env inheritance, not this PR's catalog-DELETE 404 race.

Merge this head: Sawyer-only, all checks green, no blocking defect in the 404 handling.