Shared codes render the Python title in the compact index, so Robot and JS candidates go unrecognized #172

Found in the #169 review. Real, and the data to fix it properly does not exist yet.

The defect

The generated structural index renders one title per code, taken from schema/code-catalog.json. For a code shared across languages that title is the Python form, so a compact host reading the index sees Python syntax for a Robot or JS finding.

C31 is the clearest case. The index row reads:

| C31 | py/rf | LOW | capsys.readouterr() result discarded |

reference.md defines the Robot form of the same id as any captured keyword value that is never asserted on, and says so explicitly:

This shares the id with the Python capsys C31: the Python form is a discarded readouterr(), the Robot form is a discarded Get capture. Same concept (a capture nothing asserts on), same id - documented reuse, not silent drift (#105).

So the reuse is deliberate and documented. What is missing is a per-language rendering of it. C3, C9, C23 and C44 reuse ids the same way.

Because the documented compact workflow is "work from the index, pull the reference.md passage only after the index names a candidate", a Python-centric title can stop a Robot or JS candidate from ever being recognized. That is under-detection with no signal.

What #169 did instead

Added a caveat to the index block lead in AGENTS.md, contexts/cursor.md, llm.md, and the plugin entry point: read a shared row as the concept rather than as the syntax to grep for, and pull the language passage when the row is close but the syntax does not match. That removes the misleading part without inventing data it does not have.

The caveat is a mitigation, not a fix. A reader who does not hit "close but not matching" never pulls the passage.

Why it needs new extraction

code-catalog.json holds one title per code, produced by scripts/build-code-catalog.mjs from reference.md. The per-language forms exist in reference.md prose but are not extracted, so no generator can render them today. Fixing it means one of:

1. Extract per-scanner titles. build-code-catalog.mjs learns to record a title per language section, and the catalog schema grows a titles: {py, js, rf} shape. The index then renders the row for the language in front of the reader, or renders all applicable forms. Most faithful, largest change, and it touches the schema every other check reads.
2. Render the concept rather than the syntax for shared rows. A shared code gets a language-neutral summary instead of the Python form. Cheaper, but it means authoring a third description per shared code and keeping it aligned with both language sections, which is the drift surface sync-host-files.mjs exists to prevent.
3. Mark shared rows and require the passage. The index flags a row as having language-specific forms and states that the passage is mandatory before reporting it. No new prose to maintain, but it puts a reference.md read back on the compact path for the shared codes, which is the cost the index was built to avoid.

Option 1 is the only one that keeps the index self-sufficient and single-sourced. It is also the only one that needs a schema change, so it should be decided before it is started.

Definition of done

• A compact host reading the index for a Robot or JS file sees a description that matches what it will actually find in that language.
• Whatever shape lands is generated from reference.md, not authored alongside it. Three of the defects [issue-168] fix(protocol): route every language through the semantic catalog (#168) #169 fixed came from a second hand-maintained copy of something the catalog already knew.
• npm run validate fails if a shared code gains a language form in reference.md that the index does not reflect.

Refs #168, #169.