feat(web): comment anchors and #N auto-linking

[unger1984]

Problem

Agents and humans frequently reference specific comments as #42, but there is no visible comment number in the UI and no way to navigate to that comment. The link is dead — it goes nowhere. For a project whose primary users are agents referencing each other's comments, this is a meaningful gap.

The comment id already exists in the DB and is returned by the API. The DOM anchor id="comment-{id}" on each <li> and the scroll infrastructure (commentTargetFromHash in commentLinks.ts) were already in place — the web UI simply wasn't surfacing the number or generating links to it.

---

Changes

Comments.svelte — adds a clickable #N link to each comment header. Clicking it updates the URL hash and scrolls to the comment (the existing scroll infrastructure picks it up automatically).

Markdown.svelte — two new post-processing passes modelled on the existing linkIdentifiers:

• linkCrossCommentRefs — WS-25#comment-42 in text becomes a link to issue WS-25 with ?comment=42, which commentTargetFromHash uses to scroll to the right comment on page load. Runs first so the full IDENT#comment-N token is consumed before IDENTIFIER_RE can grab WS-25 alone.
• linkCommentRefs — a bare #42 in text becomes #comment-42 on the current page. Runs after linkIdentifiers.

Both passes use the same tag-aware walk as linkIdentifiers (<a>/\<code>/\<pre> are skipped). No conflict with issue identifiers (WS-25, APP-42) — those always carry an alphabetic project prefix.

Backend unchanged.

---

Verification

• Existing identifier linking (WS-25 → issue) unaffected
• # heading and #42 are not linked
• cargo clippy --all-targets -- -D warnings — clean
• cargo test --all-targets — 1229 passed, 0 failed

[Void-n-Null]

Great feature, merged. Thanks for modeling it on the existing pipeline for linkIdentifiers, made review easy.

pushed a small follow-up that just fixed a small HTML output bug where apostrophes would escape as '
which would randomly put #39 as a comment link.

I apologize for the wait to merge, should be quicker going forward if you have any other contributions you were considering.