[rahul05ranjan]

Fixes #783.

What this changes

The two brokered_connections reads that carried no provider predicate now filter on the active brokerProvider, like the other eleven selects in connections.ts:

• retireConnectionsFor — the offboarding sweep. Before: on a deployment holding both providers' rows, the sweep would have called the active broker's revoke() for a connection filed under the other provider — a vendor that would not recognise it — while the audit row recorded vendorRevocationRequested about access that was never removed.
• brokeredConnectionsFor — the settings-page read. Before: a foreign-provider row would be silently dropped from the page when its app failed to resolve at the active provider's canonical scheme.

Both sites' comments said a future flow must add this predicate; this adds it, together with the regression test the issue's acceptance asks for. No behavior changes today: assertActivatable still refuses to boot a deployment whose rows disagree with the configured provider, so neither read can meet a foreign row — the predicate is free now and already right when the provider sunset flow relaxes that refusal.

Where it runs

• New state that outlives a request? None. Two existing SELECTs gain a predicate; nothing is written, held, or memoised.
• What happens on the second replica? Nothing new: the predicate lives in the query, so every replica reads the same rows. There are no new process-local structures.
• Anything serialised? No new writes at all. The delete after the sweep was already scoped to the inArray(brokeredConnections.app, withdrawn...) list derived from this read, so a foreign row is never deleted either — that needed no change.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• Every acting call still goes through the gateway: unchanged; this is store-internal.
• New refusals and new failures each write a row: no new refusal. The sweep skipping a foreign row is the fix, not a refusal: the trail never claims a withdrawal this deployment could not have performed.
• Nothing new is trusted from the client: unchanged.

Changelog

• A line in CHANGELOG.md under Unreleased, or a sentence on why a deployment behaves no differently afterwards: no deployment behaves differently — a mixed-provider deployment cannot boot today (assertActivatable), and on a single-provider deployment the predicate matches every row.

Proof

What I ran and read (no Postgres on this arm64 CI box, so the test itself runs in CI, not here):

• Read both reads on main at their exact locations (brokeredConnectionsFor's select, retireConnectionsFor's brokered select), each carrying the comment naming this as the sunset-flow work item.
• The predicate is byte-identical in shape to the same file's other reads, e.g. the brokeredConnection deployment-row select: eq(brokeredConnections.provider, brokerProvider).
• Read the delete that follows the sweep (inArray(..., withdrawn.map(...))): withdrawn is built from this read, so a filtered read means a foreign row is neither revoked, nor deleted, nor audited — nothing else in the method needs the predicate.
• Added offboarding does not revoke or audit another provider's rows beside the two neighboring offboarding tests: it seeds one composio row and one arcade row for the same user, runs the sweep through the same brokerSpy/freshStore harness as its neighbors, and asserts retired: 1, exactly one revoke: call, the arcade row still standing, and exactly one mcp.account_disconnected audit row (gmail, vendorRevocationRequested: true). On main the sweep reads the arcade row too, so the spy revokes it, retired is 2, the row is deleted, and two audit rows exist — every assertion in the test fails there.
• Could not run bun test locally: the suite needs a live Postgres, which this host does not have. The test follows the file's existing harness line for line; CI is the authoritative run.