Fix todos add --plan persistence verification

[andrei-hasna]

Summary

• verify the requested plan_id in the /v1/tasks authoritative create readback
• verify the requested plan_id again in remote CLI create readback
• cover built CLI, API, generated SDK/OpenAPI, SQLite, and PostgreSQL adapter paths

Root cause

Task creation already performed POST-then-GET verification, but acceptance compared only the task ID, parent link, and (when requested) creator attribution. A hosted authority could therefore acknowledge todos add --plan, return a readable task whose plan_id was dropped, and the CLI would still exit successfully.

Validation

• bun test: 3724 pass, 79 skip, 0 fail across 294 files
• focused cloud-router, /v1, built CLI, SDK/OpenAPI, SQLite, and PostgreSQL adapter tests: pass
• bun run typecheck: pass
• bun run build: pass
• bun run verify:release: pass (non-authoritative review mode)
• gitleaks protect --staged --redact --no-banner: no leaks found
• live exact-path acceptance: temporary plan-linked task created, shown by stable ID with the requested plan, commented, deleted, then exact show returned not found

Sequencing

This branch is based exactly on merged PR #264 main at ddf38513317c9c66e044b03859c1798fba835313.

Keep this PR in draft and do not begin adversarial review until release PR #262 has merged and released its hasna/todos/main lock. Then fetch and rebase onto the new protected main, rerun affected gates, and record the new exact base/head/tree before review.

Task: DUB-00027

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[andrei-hasna]

[REVIEW] GO — #265 @ f150ff3 — lens: correctness+isolation+wiring, reviewer codewith-sol-reviewer (1 of 1)

P0: None.

P1: None.

P2: None.

P3: None.

The change closes both reachable success paths for a dropped plan link. src/server/v1.ts now refuses the 201 response when authoritative storage readback does not preserve the requested plan_id; src/cli/cloud-router.ts independently enforces the same property after POST, including against older authorities. The CLI resolves --plan to the canonical plan ID before calling cloudCreateTask, so the new equality check does not reject the supported slug/short-reference path. The added router, built-entrypoint, server, SQLite, storage-contract, and PostgreSQL assertions exercise the changed wiring and persistence boundary without adding local fallback behavior or POST replay.

Could not verify: the exact head was not present in the local object store, so I inspected the supplied diff plus exact-head source fetched read-only and did not run the candidate locally. GitHub's test check for this exact head was still IN_PROGRESS; dashboard was SUCCESS. PostgreSQL integration remains environment-gated and was not executed here. No repository, PR, task, or external state was modified.