Bug: findTaskByIssueUrl URL normalisation regex strips entire path

Summary

findTaskByIssueUrl in src/lib/attempts/core.ts (line 70) tries to normalise an incoming GitHub issue URL with this regex:

const normalised = issueUrl.replace(/[/?#].*$/, "").replace(/\/$/, "");

The character class [/?#] matches the first / in the URL — which for any real GitHub issue URL is the leading / right after https:. Result: normalised is always "https:". The intended behaviour (per the comment, "trailing slashes or query strings") is to strip a trailing slash, ?, or #, leaving the path intact.

Repro

node -e 'console.log("https://github.com/owner/repo/issues/123".replace(/[/?#].*$/, "").replace(/\/$/, ""))'
# https:

So the fallback lookup against normalised can never match a stored task. When the GitHub webhook delivers an issue URL with a query string (e.g. tracking params on ?utm_*) or a fragment (e.g. #issuecomment-123), or a trailing slash, the resolver silently fails to find the task and the /attempt slash command is dropped.

Branch with failing test

bounty/fix-issue-url-normalize (PR #2 must merge first to bring vitest in.)

git checkout bounty/fix-issue-url-normalize
npm install
npm test

Output (excerpt):

 FAIL  src/lib/attempts/normalize-issue-url.test.ts > normalizeIssueUrl > strips a trailing slash
TypeError: normalizeIssueUrl is not a function

 Test Files  1 failed | 1 passed (2)
      Tests  4 failed | 3 passed (7)

Fix scope

1. Extract a normalizeIssueUrl(url: string): string helper exported from @/lib/attempts/core.
2. The helper must:
   • return the URL unchanged when it has no trailing slash / query / fragment
   • strip a trailing slash
   • strip a ? query string
   • strip a # fragment
3. Update findTaskByIssueUrl to use the helper.
4. The four tests in src/lib/attempts/normalize-issue-url.test.ts must pass; the smoke test must still pass.

Estimated diff: 10–20 LOC. No database, auth, or payments code touched. Verified end-to-end via npm test.

Suggested bounty

$50. Single-file logic fix, fully verifiable in CI, but the bug is a real silent failure in webhook routing so it's worth a bit more than a typo.