Make REPL syntax discovery distinguish unavailable components #1053

Story

As a Sidekick author, I want <REPL.Syntax> to describe where a component can actually be used, so discovering an assertion component does not send me into a submit-and-retry loop in an execution surface that cannot resolve it.

Observed failure

Two manual experiments encountered the same mismatch:

• Repository acquisition, session 8afb0de1a5206d5008d454e675f1884c: syntax discovery reported Assert, but a later draft containing it was refused at admission because it could not resolve. No entry number was issued and no effects ran.
• Asset import, session 4e8302de30ebf45c89949c9a09e81e31: AssertEquals appeared in documentation but could not resolve when submitted as an ordinary entry. Replacing the assertion with existing If/Fail composition allowed work to continue.

These are component-resolution failures, not evidence of a permission denial. Test-only assertions may legitimately be unavailable in ordinary entries; discovery must explain that distinction.

Contract

• Trace listing and named lookup through REPL.Syntax and compare them with the actual REPL.Submit validation and execution vocabulary.
• Ordinary-entry documentation identifies components usable there. Components confined to a Markdown test or another execution context are excluded or explicitly identified with that context and its supported invocation.
• Preserve the distinction between vocabulary and permissions: a component may resolve correctly and still require authorization when executed. Do not claim documentation grants permission.
• Do not enable test-only components globally merely to make documentation agree. Prefer correcting discovery, context descriptions or an actual resolver mismatch using existing component registries.
• Keep listing, named documentation, validation and execution consistent after session components or plugin configuration change.

Acceptance and evidence

Add a focused agent-free regression through the production REPL syntax and submission boundaries. Query Assert and AssertEquals by name and in the listing, then submit the smallest documented invocation in the context advertised.

Include a supported ordinary component, a test-only component in its supported test context, an unknown name, and a resolvable component whose permission is refused. These cases must distinguish resolution, execution context and authorization.

Save a small REPL experiment recording discovery, the attempted invocation, actual outcome and retry count. The corrected ordinary-entry path must not require guessing a replacement after misleading syntax output. No real model call or private journal fixture is necessary.

Relationships

#1050 addresses source interpolation when saving these experiments; it does not fix component discovery. The recorded experiments provide the initial incident evidence, not a requirement to add another public capability-discovery API.

Suggested owner: Integration Orchestrator, coordinating any shared REPL files with Main at a stable checkpoint. This issue does not alter active role calls or queues.