fix: cap huge selections before shortening

The shortcut and toolbar read window.getSelection() without a limit, so a
select-all on a very large page handed prepareAction millions of
characters. Every binary-search probe re-encoded the whole candidate
prefix: about 1.1 s for 5M characters, paid again by the dialog.

Each code point adds at least one character to the URL, so nothing past
the first MAX_URL_CHARS can fit. Cap there before any encoding. A capped
source never takes the ready path: renderPrompt trims, so a prefix of
mostly whitespace could fit and silently drop the rest without consent.

Output is unchanged: 2,000 random cases matched develop exactly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

CHANGELOG.md

@@ -11,6 +11,8 @@ All notable changes to this project will be documented in this file. See [commit
   actions, with optional translation and a preferred language or language dialog.
 - Preserve dedicated action instructions when shortening selections; ask before
   sending shortened text and reject URLs that cannot be sent intact.
+- Stay responsive with very large selections from the shortcut or toolbar: only
+  the part that can fit in the ChatGPT link is processed.
 - Add accessible action dialogs with cancellation and retry, remove the temporary
   model/effort URL probe, and document URL sharing. No new permissions.
 - Show up front, in the options panel and README, that ChatGPT may require