Ask where a TRACES tag sits, so the tool stops tagging its own fixtures

The traceability tool scans `tools/`, which is its own source, and a line was
taken for a tag whenever `TRACES:` appeared anywhere on it. Its unit-test
fixtures are therefore tags. R1 — cross-platform output within a bounded
tolerance, the requirement with no acceptance criterion at all — was reported
implemented on the strength of two string literals in
`context_looks_forward_then_backward`.

R1 was only the visible case because it had no other coverage. The same
fixtures also contributed sites to FR-CAT-1, FR-CAT-2 and NFR-P1, `gestures.rs`
contributed one to FR-UI-4 from a `push_str`, and `dr-pipeline/build.rs`
contributed FR-DEV-3a and FR-DEV-3c from the tag it *emits* into generated
code. Those four requirements keep real tags elsewhere, so nothing but noise is
lost by dropping them.

The rule is about position, not about string literals. It cannot be about
string literals: `schema.rs` writes six genuine tags inside Rust string
literals, because the SQL it embeds is commented with `--`, and an extractor
that refused those would lose more than it saved. What separates the two is
where on the line the tag is. A tag written to be read is the first word of its
comment; a tag quoted inside an expression never is. So `tag_body` asks for a
comment opener at the start of the line and `TRACES:` immediately after it.

That closes every shape but one: a multi-line literal whose lines really do
begin with `///`, which no line-oriented reader can tell from source. There is
one such fixture and its ids are now UT and IT, which `is_requirement` already
excludes from coverage — the mechanism existed and was simply never used on
the tool itself. `this_crates_own_fixtures_cannot_reach_the_register` enforces
that: any requirement id below `mod tests` in this crate fails the test and
says to use a UT- or IT- id instead. Tagging the tool's real code is still
allowed.

On `SOURCE_SUFFIXES`, which cannot reach `AndroidManifest.xml`, the Flatpak
manifest, the Dockerfile or the CI workflows: it is deliberately left alone,
and the reasoning is recorded beside it. A tag on a manifest asserts that a
comment exists next to a line nothing checks, which is the weak form
CONTRIBUTING.md warns about. The convention already in the tree — a Rust test
that `include_str!`s the file and asserts what must be in it, with the tag on
the test — is what a tag is supposed to mean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/outstanding.md

@@ -320,9 +320,12 @@ fixed before spike S9", because S9 both validates R1 and calibrates what toleran
 The threshold was never fixed and S9 has not run, so R1 currently has no acceptance criterion at
 all — there is nothing a test could assert.
 
-Worse, the matrix reports R1 as *covered*. Both of its tags are string literals inside the
-traceability tool's own unit tests (`tools/traceability/src/lib.rs`), which the tool scans along with
-everything else, because a fixture demonstrating tag extraction is indistinguishable from a tag.
+The matrix used to report R1 as *covered*, and what covered it was two string literals: fixtures
+inside the traceability tool's own unit tests, which the tool scans along with everything else,
+because a fixture demonstrating tag extraction was indistinguishable from a tag. The extractor now
+asks where the tag sits — a tag is the first word of a comment, not a string appearing anywhere on a
+line — and R1 is untagged again, which is the honest reading while it has no acceptance criterion to
+tag anything against.
 NFR-OPS-1 is covered the same way, from a tag on `compute_coverage` — and no rotating, size-capped
 on-disk log exists; logging goes to stderr and logcat. These are two of the cases
 [CONTRIBUTING.md](../CONTRIBUTING.md) already warns about, now named.