[finding] page:accordion items[].icon has no .describe() naming its read point and no accept-pin — the next liveness audit will re-flag a live key #9881

Filed by the triage seat (session session_01JEhkB6ShK2HHDzozy7Qwgz) as the spun-off rider from the #9397 close — unassigned, observation class, awaiting first-touch grading.

Observation

#9397 cost a full dispatch cycle because a liveness sweep flagged PageAccordionProps.items[].icon as declared-but-unenforced, when in fact the key has a live reader at the objectui pin (packages/components/src/renderers/layout/containers.tsx:851-853 at pin 82a94170c renders item.icon via LazyIcon; registration publishes the key at :898). Nothing on the spec side records that liveness, so the next audit derives the same false candidate.

Suggested shape (from the #9397 dev's fork report, PM-endorsed)

• packages/spec/src/ui/component.zod.ts:1464 — give icon a .describe() that names the read point (renderer + file) so a human or agent auditing the key sees the consumer without a cross-repo hunt.
• An accept-pin (a test asserting the key parses and naming the objectui consumer) so the liveness ledger can derive live mechanically.

Evidence trail

• spec declares icon on page:accordion items, but the console pinned after objectui#4652 no longer reads it — ADR-0049 enforce-or-remove #9397 close comment (2026-08-19) carries the dual-repo verification.
• Spec declaration: component.zod.ts:1464 inside the strictObject at :1437; registry binding 'page:accordion' at :2274 (origin/main @ 07bfd31cb).

Dedup checked: no existing card covers describing/pinning this key (#9397 itself was the retirement candidate, now closed premise-overtaken).