Issue notifications can exceed Discord’s 2,000-character content limit

Problem

At d011621, notifyDiscord() joins every new issue for a repository into one content string and sends it without a length check. Discord documents a 2,000-character webhook content limit.

A batch of 30 issues with ordinary-length titles exceeds that limit. A rejected send also escapes the sequential repository loop in main(), so later repositories are not notified in that run.

Reproduction and local validation

Use 30 issue records with numbers 1–30, title "A realistic notification title ".repeat(3), login contributor, and URLs https://github.com/example/repo/issues/1 through /30. The existing message construction produces one over-limit payload.

I extracted the actual notifyDiscord() function and ran it under Node 22.23.2 with an inert send stub that rejects content over 2,000 characters. The original function rejects; a local patch sends bounded chunks whose concatenation exactly preserves all 30 records.

Nine local checks pass: the before/after notifier case, empty content, exact limit, one character over, a surrogate pair at the boundary, multiline content, a long individual line, an empty issue list, and propagation of transport failure without automatic retry. These are source-function tests with a stub transport, not a live Discord or scheduled-workflow test. Bun-native helper tests are prepared but have not been run; full build/typecheck are also unverified.

Proposed fix and scope

Split content at complete lines where possible, fall back to a bounded split without breaking UTF-16 surrogate pairs, send sequentially, and preserve allowedMentions: { parse: [] }. This is separate from displaying bounty amounts in notifications.

Would a narrow PR for this fix be welcome, and would an accepted contribution fall under the current contributor sponsorship program? No fixed bounty or sponsorship payment is assumed.

Start in scripts/issue-notifications.ts at notifyDiscord() and inspect how issue records become one webhook content string. Run the prepared source-function checks with the stub transport, including boundary and surrogate-pair cases. Done means bounded sequential sends preserve all records and allowedMentions, while transport failures still propagate.