Whole-branch code review brief: Plans 1 (catalog and account limits)

You are a senior Go reviewer on the carlos platform. Review the implementation of Plan 1 on branch design-plans-and-caps, range 3d444a1b..HEAD (git diff 3d444a1b..HEAD; ignore the docs under docs/superpowers/ except as requirements). The review is read-only: do not modify the working tree, index, HEAD or branches, and do not build into the repo. You may run go test for packages you want to probe.

Requirements, in order of authority:

1. Spec: docs/superpowers/specs/2026-10-20-plans-caps-packs-design.md (sections 4, 7, 8.7, 9.4, 10 are what Plan 1 implements; section 3 lists product decisions that are not to be argued with).
2. Plan: docs/superpowers/plans/2026-10-20-plans-1-catalog-and-limits.md.
3. The executor's rulings (deviations from the plan, each with its cost): .superpowers/sdd/2026-10-20-plans-1-catalog-and-limits/progress.md, lines containing Ruling:. Weigh each; say if any is wrong.

The spec is a vision document. For behaviour it is silent on, judge by what a reasonable operator or customer would expect, and grade by effect.

Check these deliberately (the plan's Review Focus, inputs its tests may not exercise):

1. A catalog edited without a version bump: the console must refuse to start or treat it as new, never publish records whose catalog_id lies.
2. A catalog change that orphans an assignment (plan or pack removed): skip that account, keep its last record, keep publishing everyone else.
3. A deleted (tombstoned) account: no row ensured, no record written.
4. An operator change racing the publish pass: the newer revision wins in the bucket and in published_revision; a stale publish never marks a newer revision published.
5. Partial sponsored limits: unset fields leave the plan's value; minscheduleseconds 0 must not mean "no minimum".

Also look hard at: the host-claim boundary (hostops classifier entry for accounts/<sqid>/limits.json, claim fixtures and probes), behaviour with CARLOSPLANCATALOG unset (must be exactly today's behaviour), the operator door's authorization (fleet operators only; everyone else gets the stdlib 404), CAS and retry correctness in publishAccountLimits, SQL in accountplans.go, and cross-compilation (darwin/windows).

Do not review the wording of human-facing strings: they passed Paul's copy review and are applied verbatim (accountsplancopy.go, internal/console/apiaccountplan_copy.go, docs/site/plans.md, the cli.md entry, nav.json, the accounts usage block).

Output format:

• Findings, most severe first, each labelled Critical / Important / Minor, with file:line, the concrete failure scenario, and the fix you suggest.
• "Declined to judge": every behaviour you considered and set aside as outside the plan or spec, one line each with the reason.
• A verdict: ready to merge, ready with fixes, or not ready.