Drop the old connector tables

[davidmckayv]

What this changes

Clears the last of what #124 flagged and left. connector_instances, connector_cursors, webhook_subscriptions and sync_runs go, with the connector_type and sync_status enums that existed only for their columns.

These four were the bookkeeping for the worker that filled the document index dropped in #126: which sources were configured, where each sync had reached, which webhooks were registered with the vendor, and how each run went. #97 removed server/src/connectors.ts and the worker's sync runner, which were the last code that touched them.

Worth correcting one thing in #124's notes, because it was true when written and is not now. It listed connector_instances as live, on server/src/connectors.ts selecting, updating and inserting against it. That file no longer exists. Nothing outside core.ts and schema.test.ts references any of the four, so this is the whole subsystem rather than the three leftovers it looked like an hour ago.

knowledge-agent.ts, the fourth thing #124 flagged, is already gone. #97 took it.

What is lost, and what is not

Operational history rather than anybody's content: cursors, run outcomes, and each source's source_metadata. Still worth the warning at the top of the migration, since it cannot be rolled back.

No credential goes with it, and I checked rather than assuming. The vault pointer was credential_id on the connector row with ON DELETE SET NULL, pointing at credentials, not the other way round. Seeded a connector credential, attached it to an instance, ran the migration:

credential survived: id=3333…3333 kind=connector value=ciphertext-here
credential_kind still has connector: 1

A webhook registered at the vendor is not withdrawn by this, and the migration says so instead of implying the vendor side is clean. Nothing has listened to those deliveries since the connector was removed and the subscription lapses on its own, but a deployment that wants it gone now has to revoke it at the vendor.

credential_kind keeps its connector value. That is a kind of secret, not a row in these tables. Removing a value from an enum that is in use is a different question from removing a table nothing reads, and it is not this PR's.

"Connector" still means something

The per-person plugin connectors from #97 live in the plugins schema, are untouched here, and are what /admin/plugins configures. The docs that talk about connectors are describing those, so no doc change: docs/architecture.md:22 says this database holds connector state, which stays true of mcp_servers, plugin_grants and mcp_user_credentials.

Where it runs

No new state outliving a request, nothing different on a second replica, nothing serialised, nothing fanned out to a browser, no new listener, port or schedule. One migration and the declarations it follows from.

Boundary and audit

N/A. No gateway, policy or audit path touched.

Proof

Driven against a real Postgres.

Upgrade path with rows in all four, migrated to main (0010) first, then a credential, an instance pointing at it, a cursor, a webhook subscription and a completed run:

before: instances=1 cursors=1 webhooks=1 runs=1 credentials=1
after:  connector tables left: 0
        connector_type/sync_status types left: 0
        credential survived: id=3333…3333 kind=connector value=ciphertext-here
        credential_kind still has connector: 1

Fresh database, 0000 → 0011: applies clean.

Migration chain:

$ bunx drizzle-kit check --config=drizzle.config.ts
Everything's fine 🐶🔥

$ bunx drizzle-kit generate --config=drizzle.config.ts --name=ci_drift_probe
No schema changes, nothing to migrate 😴

Suite, against a database migrated to 0011:

	result
bun run test	1138 pass, 5 skip, 0 fail, 1143 across 102 files
bun run typecheck	clean, all four packages
bun run format:check	clean
bunx biome lint .	1 info, identical to main
bun run build	clean

Same two choices as #126

Named in dependency order and dropped without CASCADE, so a fork that hung something off these gets a failed migration that changes nothing rather than a silent removal. The whole file is one transaction, so it is all or nothing.

No changelog entry. The Unreleased entry is being written elsewhere and I did not want to collide with it.