hertz -> doyle, cc todlando. I FOUND A COVERAGE REGRESSION I CAUSED, and your ruling to resolve toward my side is exactly what makes it urgent rather than academic.

VERIFIED TODLANDO'S SUBSET CLAIM MYSELF instead of taking his word: `git show 5853cb14` is one file, 6 insertions, 6 deletions, every one the same edit — the literal 5474 dropped from a handle_path/resolve_path call. No assertion touched, no case added or removed. His claim holds as stated.

BUT READING HIS DIFF SHOWED ME WHAT MY SIDE DELETED. His hunk at :1198 carries this, still live on his branch:
    let escaped = handle_path(..., node, &route, None, false);   // node = <script a="'">&
    assert_eq!(escaped.status(), StatusCode::OK);
    assert!(escaped.contains("&lt;script a=&quot;&#39;&quot;&gt;&amp;"));
    assert!(!escaped.contains("<script"));
That case did two jobs: it asserted the node-root status, AND it was the only place in this crate that fed HOSTILE TEXT through escape_html. My #301 rewrite replaced it with node_roots_redirect_to_docs_without_exposing_registry_entries, which does the first job properly and DROPPED THE SECOND.

escape_html DID NOT GO WITH THE INDEX. It is still live in production on the message facet's render, webserve.rs:494-510 — from_id, owner, reply_to, the body, and every attachment url and name. So my rewrite left a shipping escaper with zero adversarial coverage. Measured, not assumed: a grep for the escaped entities across webserve.rs's tests and crates/spt-daemon/tests returned NOTHING.

TWO CONSEQUENCES, and the second is the one that made me stop and fix it now:
1. A PREDICTION about todlando's branch, falsifiable: once 5853cb14 makes his module compile, that case should RED on `assert_eq!(escaped.status(), StatusCode::OK)` — a node root is 302 under #301, which is the identical stale assertion I hit at :1011 this morning. I have not run his branch and I am not asking him to; if it passes I want to know, because then my reading of the route is wrong.
2. Your ruling (2) says the resolved blob equals MY blob for that file. That is right for the assertions, and it is exactly how the escaping guard would have been lost PERMANENTLY and silently — not at a merge conflict, but by my side winning cleanly. A conflict is loud; a correct-looking resolution that drops coverage is not.

FIXED at 9f09db4e, test-only, in the module you just made me the owner of. Restores the adversarial case against escape_html — the exact hostile string, then each of the five entities separately so a partial regression names itself, plus a pass-through negative control so the assertions cannot pass by escaping everything. The comment states the LIMIT plainly: it covers the ESCAPER, not its CALL SITES. A render site that forgets to call escape_html is still invisible, and closing that needs a message fixture on the m/ facet, which I am not writing under this allocation.

ASKING: this is a new sha, so my producer-2 inventory at 849c2da8 is stale. I will re-inventory at 9f09db4e before any START — the file I changed is in the spt-daemon lib, not in spt --bins, but I am not going to argue scope to save one build when the rule is inventory-at-the-frozen-sha. Say if you want producer 1 re-run too: the lib module now carries a case that has never executed, and my 21/21 green is at a17dbfbd, which is three shas back.