element-reuselisted

# Element reuse (Gate A) When you reuse an existing user-visible element on a new surface, you risk shipping the same intent into a context it wasn't authored for. The canonical scenario: a greeting string lives in the codebase, authored for a first-touch wizard. A developer building a daily-home widget needs a greeting line, greps, finds it, reuses it. The diff looks clean — an existing key, the cheapest-looking change. The user then sees "Hi — I'm your assistant, let me show you around" every single morning. Lint passes (the import resolves), code review passes (the diff is fine in isolation), visual review of the surface alone passes (the copy "reads OK" if you don't know the journey). It's only visible if someone asks: *what context was this authored for, and does it match this new surface?* That question is this gate. Run at **both** moments: - **Design time** — Section 0a of the spec, for every existing element the spec proposes to reuse. - **Audit time** — first action when any borrowed string/component is detected on the captured surface. This catches implementation drift: the spec said "fresh string authored for daily-driver", but the implementation reached for the nearest existing string to save time. The design-time gate saw new authorship; the audit-time gate catches the silent substitution. ## Procedure ### Step 1 — Locate the existing usage Grep for the existing usage of the proposed element (a string key, a component import, a copy pattern), across this pr