fix(lokee): bind revert execute to history database identity

[cursor]

Bug and impact

POST /lokee/databases/:id/revert planned reverse DDL from the History database (:id) but executed it on whatever connection the client sent. The History UI uses separate dropdowns for history database and credential, so a user can select DB A’s history and DB B’s credential, then apply A’s reverse migration to B — wrong-target DDL / possible data loss.

Root cause

Revert only checked that the history row was owned by the user (assertOwned / planRevert). It never compared the resolved connection’s databaseIdentity fingerprint to lokee_databases.fingerprint.

Fix

• Add LokeeWeaveStore.matchDatabaseIdentity.
• Before planning/executing revert, require the connection fingerprint to match the history row; otherwise return 409 with code: "connection_mismatch".
• Surface that code through LokeeRevertError in the client API.

Validation

• npx vitest run apps/web/src/backend/modules/lokee-weave.module.test.ts — 40 passed (includes new match/mismatch/not_found cases).
• cd apps/web && npx tsc --noEmit — clean.

  

---

Note

Medium Risk
Changes revert execution safety by blocking wrong-target DDL; scope is limited to one endpoint and fingerprint comparison, but mistakes here could still block legitimate reverts if identity hashing diverges from capture.

Overview
Revert execute now refuses to run when the client’s resolved connection does not match the schema history row (:id). Before planning or applying reverse DDL, the handler compares the connection’s databaseIdentity fingerprint to lokee_databases.fingerprint via new LokeeWeaveStore.matchDatabaseIdentity.

On mismatch the API returns 409 with code: connection_mismatch`` (404 when the history id is missing or not owned). The frontend LokeeRevertError and `executeLokeeRevert` parsing recognize that code so the UI can prompt the user to pick the credential for the same database.

Tests cover ok, mismatch (different database name), and not_found.

^{Reviewed by Cursor Bugbot for commit b88b9e2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_047cbbbf-b86f-4be2-aaf2-c3fe56e9c497)