Guide LLM consumers on component selection order and custom component creation

`", "no
`style={{}}`", "use the CLI to read props") and a 3-step lookup workflow. But two gaps remain:

**1. Unclear prioritization — which component to use, in what order.**
When building in a project, models have no guidance on the order to reach for components (e.g.
existing app components → Astryx semantic → Astryx primitives → custom). They pick somewhat
arbitrarily and often jam in an ill-fitting component.

**2. Unclear fallback when Astryx is missing a component.**
When nothing in Astryx fits, models don't know *where* to put a custom component or *how* to
build one that works with the system (composing from Astryx primitives/tokens, cribbing
hooks/behavior from similar Astryx components) — so they tend to hand-roll a one-off with raw
CSS in an arbitrary place.

## Failure cases (to collect)

Before proposing any fix, gather real prompts/scenarios that exercise each problem above. These
become the inputs for vibe testing.

- _(Problem 1) (add cases: model chose the wrong component / wrong priority order)_
- _(Problem 2) (add cases: model hand-rolled raw CSS / put custom component in the wrong place)_

## How we want to solve it

Whatever guidance we add must be **vibe tested** — not just written and assumed to work. A
solution only counts if the LLM can *discover* the guidance (find it in the docs surface it
actually reads) and *apply* it (measurably better component choices / custom-component patterns
on the collected failure cases). Iterate on the doc/guidance changes and keep what measurably
moves the needle.

## Where a fix would likely land

- The generated agent cheat sheet in `packages/cli/src/commands/agent-docs.mjs`
(`generateCompressedIndex`) — the surface every LLM consumer actually sees.
- Possibly mirrored/expanded in the `working-with-ai` guide
(`packages/cli/docs/working-with-ai.doc.mjs`).