Show the response ID, and assert user text stays out of the log

[Robbie1977]

The response identifier was never rendered

The DPIA describes a data-subject-rights route in which someone asks about the data held on a particular exchange by quoting its response identifier. The identifier was generated and stored from the start and never shown, so the route could not be exercised and an assessor could disprove it in a browser in under a minute.

It now appears under every answer, not only the latest — the feedback prompt is deliberately rendered once at the foot of the conversation, but the answer someone wants to ask about is often not the last one. Quiet: 0.68em, muted, below the sources line, selectable, with a copy button that degrades to "select and copy" where the clipboard API is unavailable. The privacy notice says what the ID is for, since we hold no account and no name and it is the only way to find the records for one exchange.

Nothing asserted that A1b stayed closed

safeToolArgs renders tool arguments by shape rather than by value, and nothing tested it. The surface had already been widened three times by diagnostics added for good reasons, each caught by somebody reading the code rather than by a failing test.

The new test drives the real paths — runHarness with mocked ELM and MCP, the absence escalation, the absence gate, the tool-failure reporter — with a canary planted where the user's text enters, and asserts it never reaches the console. Being behavioural rather than a grep, a new diagnostic that interpolates user text fails it without anyone remembering the file exists.

It caught four live leaks, all in orchestrator.mjs, none of them tool arguments — which is why safeToolArgs did not cover them:

• the requested term name in get_term_info FAILED
• the requested term name in deprecated term redirected
• the verbatim absence sentence in ABSENCE ESCALATION
• the removed sentence in ABSENCE GATE

A term name is often the user's phrase, and an absence sentence is prose the model wrote by restating the question — the model writes a denial by restating what was asked, so the wording comes back out in it.

The two term names go through safeText, a sibling of safeToolArgs with the same VFB_HARNESS_TRACE escape hatch: term=<text:27>. A term name has no shape worth reporting, and the line already carries the ontology id, which says which lookup failed far more precisely than the name did.

The two absence lines get something better than a length. Each entry in ABSENCE_PATTERNS now carries a short stable slug and findAbsenceClaims reports which one matched, so the log reads:

[VFBchat] ABSENCE ESCALATION | queries=SubClasses@FBbt_00005095,… | claimed=absence:does-not-hold | len=63
[VFBchat] ABSENCE GATE | removed=1 | licensed=false | absence:does-not-hold

That is strictly more useful than the sentence was — the shape of denial is countable across runs, so a rise in no-data-in becomes something you can see — and it carries none of the user's wording. repairUnlicensedAbsences returns the slugs alongside the strings rather than instead of them; the strings still reach the per-request trace, which is off unless VFB_HARNESS_TRACE is set.

Net effect: the ids, counts and query types that make these diagnostics useful are unchanged, and no free text reaches the container log on any path.

How to test

npm test (8 new cases in tests/unit/consoleLeakGuard.test.mjs). The WCAG job covers the new button; check the copy control by keyboard on the deployed build.