GeezerVison

Stacked on #6568 → #6567 → #6565 → #6560. Review only this PR's own commits; merge after its parents.

v1 is the live public API. It was rewritten to delegate to the shared application layer, and three response behaviors drifted from origin/main.

1. Failed SQL and bound parameters leaked in 500 bodies

performDeleteTable / performDeleteTableRow return toError(error).message for unclassified throws, and both routes rendered outcome.error verbatim. Both delete paths run inside locked transactions, where drizzle wraps a throw in a DrizzleQueryError whose message is the failed SQL. main returned a fixed generic string.

Reverting the fix shows exactly what any API-key holder could harvest:

- "error": "Failed to delete table",
+ "error": "Failed query: delete from \"user_table\" where ... params: 2222..."

2. The 423 lock field was dropped

main returned { error, lock }; these routes returned { error } only, while still computing lock and discarding it. lock is the only thing telling a client which lock to clear.

3. Duplicate table name: 400 → 409 — keeping 409

This changed on POST /api/v1/tables, and the recommendation is to keep the new status rather than restore parity:

• The OrchestrationError TSDoc documents the exact failure mode this replaced: "adding 'already exists' to a message demoted a 409 to a 400." Main's 400 came from string-matching 'already exists' — the anti-pattern the typed-code migration exists to kill.
• v1 knowledge, v1 files, and v1 workflow-import already return 409. Tables was the lone outlier.
• There is no v1 OpenAPI spec (all seven generated docs are v2), the v1 contract declares no error statuses, and no in-repo consumer branches on it.

Tradeoff accepted: a client matching 400 specifically for a name collision now sees 409 — but such a client already needs a 409 branch for every sibling v1 endpoint.

Fix

One shared projection, orchestrationOutcomeErrorResponse, the result-returning counterpart to the existing throw-path helper. Applied at nine call sites across three v1 and three internal table routes; statusForOrchestrationError no longer appears in any of them. It reuses messageForOrchestrationError, which genericizes only unclassified/internal — classified errors keep their specific text.

Also removes the rowWriteErrorResponse alias (15 sites): one touched file imported both names for the same function object and used one in PATCH, the other in DELETE.

Deliberately not converted: import, import-csv, and restore still hand-roll the projection. Converting them is a behavior change, not a tidy — the hand-rolled form returns outcome.error when errorCode is undefined, and that widening is the leak fix. It belongs in a change that owns the behavior.

Reverting turns 6 tests red. type-check · biome · 1113 tests · check:api-validation · check:openapi — all pass.