fastapi mount scan: a single-line string containing include_router still emits — the limitation is deliberate but nothing pins it

Follow-up from the #6415 review. The masker added there blanks `#` comments and triple-quoted regions before scanning for `include_router`, so a mount inside a docstring no longer becomes graph data. **Single-line string literals are deliberately not masked**, so this still emits: ```python X = "app.include_router(r, prefix='/x')" ``` The omission is intentional and the reason is real: the prefix *value* has to be readable out of the masked copy, so short literals are skipped over rather than blanked. Blanking them would break the feature. A full Python tokenizer is the only clean fix and is not cheap. **The part actually worth fixing is that no test pins this either way.** The behaviour is currently accidental — nothing would notice if it changed in either direction, and nothing tells a future reader it was a decision rather than an oversight. Given that the whole point of the #6415 review was that an untested branch is trusted anyway, leaving this one unpinned reproduces the same mistake in miniature. ## What to do Add a test asserting the **current** behaviour, with a comment stating it is a known limitation rather than a desired property. That is the honest shape: it documents the trade-off, it fails loudly if someone changes the masker in a way that accidentally covers or worsens this case, and it does not pretend the limitation is a feature. Do **not** attempt the tokenizer. If someone later wants the real fix, this test becomes the thing they update, which is exactly the signal that should be there. ## Assessing the exposure first Worth a quick measurement before writing anything: how often does a full `include_router(...)` call, with a literal `prefix=`, appear inside a single-line string in real Python? My guess is close to never outside of test fixtures and code-generation templates — but that is a guess, and if it is right, the test-only outcome above is clearly correct. If it turns out to be common in generated code, this changes shape and should be re-scoped. The false positive it produces is bounded: it mints a `url_mount_point` synthetic with a prefix that does not correspond to a real mount. Per #6417 that pollutes the per-repo prefix set and can only mint a link if a real producer happens to sit under that prefix. Bad, but narrow. Refs #6385, #6415, #6417.