fix(telemetry): migration 0099 matched inside words and mangled rows (#3925)

Found post-deploy, by reading the telemetry it had just rewritten.

The token it was written for IS gone — `TOK=[redacted:token]` where a
credential used to be. But `<task-notification>` came back as
`<ta[redacted:token]>`, across rows, because `sk-` matched INSIDE the word:
`sk-` + `notification` is a vendor prefix followed by twelve word characters.

TWO PORTING MISTAKES, COMPOUNDED. The live scrubber's pattern begins with
`\b`; the migration's inlined copy had no boundary at all, dropped when I
ported it to SQL. And `\b` would not have saved it either — in Postgres ARE
`\b` is a BACKSPACE, not a word boundary. `\m` (start of word) is the
spelling that means what Python's `\b` means. Two things that look
interchangeable, are not, and fail in the same direction.

The live scrubber was never affected, and the evidence says so cleanly: rows
written after the deploy carry `<task-notification>` intact, while
migration-rewritten ones are mangled. Only the frozen copy was wrong.

THE DAMAGE HERE IS PERMANENT. The UPDATE overwrote the only copy of that
text, so those rows cannot be restored. What this fixes is every OTHER
install: 0099 has run exactly once, on one instance, and shipping a known
evidence-destroying migration in the chain for everyone else would be the
worse half of the mistake. The docstring records what it cost rather than
tidying it away.

The guard pins the property no reader can eyeball — `\m` present, `\b`
absent, in both patterns — and is falsified against the shape that shipped.

This is the third time this scrubber has eaten evidence it should not have
(`--author=`, then `task-notification`), and the pattern is consistent: the
redaction half is easy to verify and the SURVIVAL half only fails on inputs
I did not think to include. The evidence set is where the work is.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011cPyzNnegXHr5iRMzzy5KJ

tests/test_retrieval_query_scrubbing.py

@@ -133,3 +133,42 @@ def test_the_write_path_scrubs_rather_than_the_read_path():
     assert "[redacted" in payload["query"]
     # The rest of the command survives, or the row stops being evidence.
     assert "git push" in payload["query"]
+
+
+# ── the SQL twin has its own word-boundary spelling (#3925) ─────────────
+#
+# Migration 0099 carries an inlined copy of these patterns, deliberately: a
+# migration is a frozen record of what already ran, and importing the live
+# ones would mean it quietly did something different next year.
+#
+# Frozen is not the same as correct, and the first cut was neither. The
+# boundary was dropped in the port, so `sk-` matched inside any word
+# containing it — `<task-notification>` became `<ta[redacted:token]>` across
+# thousands of rows on the one install that ran it. And writing `\b` would not
+# have saved it: in Postgres ARE `\b` is a BACKSPACE, not a word boundary.
+# `\m` (start of word) is the spelling that means what Python's `\b` means.
+#
+# So this pins the property no reader can eyeball, and it is a PRESENCE check
+# on a token that must appear rather than an absence check on prose (#3352).
+
+def test_the_migrations_patterns_anchor_to_a_word_start_the_postgres_way():
+    """`\\m`, never `\\b` — the two are unrelated in Postgres."""
+    import pathlib
+
+    src = (pathlib.Path(__file__).resolve().parents[1]
+           / "alembic" / "versions"
+           / "0099_scrub_secrets_from_retrieval_logs.py").read_text()
+
+    for name in ("_TOKEN", "_ASSIGNED"):
+        line = src.split(f"{name} = (")[1].split(")")[0]
+        assert r"\m" in line, (
+            f"migration 0099's {name} no longer anchors to a word start. "
+            f"Without it a vendor prefix matches INSIDE a word — `sk-` in "
+            f"`task-notification` is the case that actually happened — and "
+            f"the UPDATE overwrites the only copy of the text it mangles."
+        )
+        assert r"\b" not in line, (
+            f"migration 0099's {name} uses `\\b`, which is a BACKSPACE in "
+            f"Postgres ARE rather than a word boundary. Python's `\\b` and "
+            f"Postgres's `\\m` look interchangeable and are not."
+        )