fix(routing): ask the path whether this is a content page, not the whole URL

[adamjohnwright]

Finding 3 of the adversarial review of #184/#181. Findings 1 and 2 went in with #185; this one was pushed to that branch after it had already auto-merged, so it never reached main. Same commit, its own PR.

Both effects that write pathway browser state into the URL stood down like this:

if (this.router.url.includes('content') || this.router.url.includes('query')) return;

The query string answers that as readily as the path does. sample holds a column name taken verbatim from the reader's own expression file, and analysis.service.ts:520 sets it automatically to the first column — so an expression file whose first column is called "GC content" puts ?sample=GC__content in the URL, and from that moment nothing the reader did was written to the URL again. Not selecting a node, not flagging, not changing tab. None of it survived a reload, and none of it was in any link they shared.

Now one exported predicate testing whole segments of the path only. "query" is gone rather than fixed: the search page is content/query, already covered by the content test, and of the two words it is the likelier to turn up in somebody's data.

Verified

• e2e/content-page-urls.spec.ts (new) — the three content pages keep their own addresses, which is what the guard is actually for and had no coverage at all; and the pathway browser still writes its URL under ?sample=GC__content.
• Confirmed to be a regression test rather than a description by putting the substring guard back and rebuilding: that case fails on it, passes on this.
• 6 unit cases on isContentRoute, including the four URLs the old guard got wrong.
• check:types, format:check, lint clean; 14 tests in url-state.service.spec.ts.

🤖 Generated with Claude Code