fix(qa): keep tracker ids out of the ledger's runtime strings

`check:doc-authoring` caught two ids I had put in string prose rather than in
an adjacent comment: one in the new `cel-select-option-visible` enforcement and
one in the `cron-declared-unwired` note. A runtime string reaches authors and
operators who cannot resolve `#NNNN`; the reader who can resolve it reads the
source. The ids move to comments, and the note now says what changed rather
than which card changed it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D47qPfEWVPmhguWgBZCi5N

Author: claude

packages/qa/dogfood/test/expression-conformance.ledger.ts

@@ -156,12 +156,12 @@ export const EXPRESSION_SURFACE: ExprSurface[] = [
     // the action-param side (`cel-action-param-option-visible`, "a SEPARATE row
     // from `cel-ui` because the evaluator differs"); the field side never got
     // it, because discovery could not hand the ratchet a second key to be
-    // unclassified about.
+    // unclassified about. The server-side enforcement itself is objectui#2284.
     id: 'cel-select-option-visible',
     summary: 'choice-field per-option gating (SelectOption.visibleWhen) — the one visibility predicate the SERVER also enforces',
     dialect: 'cel', mode: 'interpret', state: 'enforced', failPolicy: 'fail-soft-log',
     enforcement:
-      'objectql/src/validation/rule-validator.ts per-option enforcement (objectui#2284) → `ExpressionEngine.evaluate` against the merged `record` + `previous` + `current_user`, re-evaluated ON WRITE for the PICKED value(s) of a written select/multiselect/radio/checkboxes field: a clean FALSE pushes an `invalid_option` field error and the write is refused. Unchanged persisted values are left alone. A predicate that cannot be evaluated (missing referenced field, or an unbound `current_user` on a system write) is FAIL-OPEN — logged with the reason and allowed through — so a broken cascade predicate never bricks a write, and authorization gating depends on the engine binding `current_user`. The console evaluates the same predicate to hide the option, which is UX only: a caller can still submit a hidden value, which is why the server re-checks',
+      'objectql/src/validation/rule-validator.ts per-option enforcement → `ExpressionEngine.evaluate` against the merged `record` + `previous` + `current_user`, re-evaluated ON WRITE for the PICKED value(s) of a written select/multiselect/radio/checkboxes field: a clean FALSE pushes an `invalid_option` field error and the write is refused. Unchanged persisted values are left alone. A predicate that cannot be evaluated (missing referenced field, or an unbound `current_user` on a system write) is FAIL-OPEN — logged with the reason and allowed through — so a broken cascade predicate never bricks a write, and authorization gating depends on the engine binding `current_user`. The console evaluates the same predicate to hide the option, which is UX only: a caller can still submit a hidden value, which is why the server re-checks',
     covers: ['data/field.zod.ts:SelectOptionSchema.visibleWhen'],
     proof: 'packages/objectql/src/validation/rule-validator.option-visibility.test.ts',
   },
@@ -367,7 +367,7 @@ export const EXPRESSION_SURFACE: ExprSurface[] = [
       'system/cache.zod.ts:CacheWarmupSchema.schedule',
       'system/disaster-recovery.zod.ts:BackupConfigSchema.schedule', 'system/disaster-recovery.zod.ts:DisasterRecoveryPlanSchema.schedule',
     ],
-    note: 'EXPERIMENTAL — five declared cron slots with no runtime evaluator (ADR-0049 enforce-or-remove candidates; each wants its own look, and the card that surfaced them says so rather than proposing a sweep). ⚠️ TWO of these surfaces are declared TWICE: `api/export.zod.ts` `cronExpression` on `ScheduledExportSchema` and on `ScheduleExportRequestSchema`, and `system/disaster-recovery.zod.ts` `schedule` on `BackupConfigSchema` and on `DisasterRecoveryPlanSchema` (the DR `testing` block). Both pairs are genuinely the same surface twice, so one row is honest here — and since #15500 each position carries its OWN key, so that judgement is now written out as two `covers` entries instead of being assumed by a collapse. ⚠️ The `failPolicy` on this row is `compile-error` because the PARSE is the only thing that ever refuses one of these values; it is not a claim that cron SYNTAX is checked. It is not: `@objectstack/formula` cronEngine validates 5/6-field patterns and `@` aliases, and has ZERO consumers outside packages/formula — nothing routes these slots through it. And per the sibling finding on the dialect union, the envelope arm of `CronExpressionInputSchema` accepts any declared dialect, so even the parse does not pin these to `cron`.',
+    note: 'EXPERIMENTAL — five declared cron slots with no runtime evaluator (ADR-0049 enforce-or-remove candidates; each wants its own look, and the card that surfaced them says so rather than proposing a sweep). ⚠️ TWO of these surfaces are declared TWICE: `api/export.zod.ts` `cronExpression` on `ScheduledExportSchema` and on `ScheduleExportRequestSchema`, and `system/disaster-recovery.zod.ts` `schedule` on `BackupConfigSchema` and on `DisasterRecoveryPlanSchema` (the DR `testing` block). Both pairs are genuinely the same surface twice, so one row is honest here — and now that each declaring position carries its OWN key, that judgement is written out as two `covers` entries instead of being assumed by a collapse. ⚠️ The `failPolicy` on this row is `compile-error` because the PARSE is the only thing that ever refuses one of these values; it is not a claim that cron SYNTAX is checked. It is not: `@objectstack/formula` cronEngine validates 5/6-field patterns and `@` aliases, and has ZERO consumers outside packages/formula — nothing routes these slots through it. And per the sibling finding on the dialect union, the envelope arm of `CronExpressionInputSchema` accepts any declared dialect, so even the parse does not pin these to `cron`.',
   },
 
   // ── TEMPLATE dialect (#15027) ─────────────────────────────────────────────