jetbrains-toolbox: add uninstall quit

[aholland]

Adds uninstall quit: to the JetBrains Toolbox cask — the same treatment as calendr (#269810), for the same reason.

The cask already tries to handle the resident menu-bar process, but with signal:, which brew upgrade deliberately skips (UPGRADE_REINSTALL_SKIP_DIRECTIVES in brew's cask/artifact/uninstall.rb). So an upgrade swaps the bundle on disk while the old process keeps running. On my machine, yesterday's 3.6.1 → 3.6.2 upgrade left a 3.6.1 process (running since 8 July) in the menu bar, offering "Download update" to the version already sitting on disk — and taking that offer would replace the brew-managed install with an unquarantined self-update. quit: runs during upgrades, and brew reopens the app on the new version afterwards.

The signal: directive stays: it still serves plain uninstalls as the escalation when quit isn't enough. The bundle id matches the existing launchctl/signal directives.

---

After making any changes to a cask, existing or new, verify:

• The submission is for a stable version or documented exception.
• brew audit --cask --online jetbrains-toolbox is error-free.
• brew style --fix jetbrains-toolbox reports no offenses.

---

• AI was used to generate or assist with generating this PR. Please specify below how you used AI to help you, and what steps you have taken to manually verify the changes, including zap stanza paths.

Diagnosed and written with AI assistance (Claude / Claude Code) under my direction and review. How AI was used: to trace why the resident Toolbox survived a brew upgrade (the verbose upgrade log shows the launchctl removal but no signalling line; the surviving process predates the upgrade by a week) and to locate the cause in brew's UPGRADE_REINSTALL_SKIP_DIRECTIVES. Manual verification: bundle id com.jetbrains.toolbox matches the cask's existing launchctl and signal directives (the zap stanza is unchanged); brew style clean and brew audit --cask --online error-free against the edited cask.

---

[aholland]

Apologies for the noisy timeline: the close/reopens and force-pushes were retries against the GitHub attestations/REST API outage (16–17 July UTC), which failed CI during tool install and cancelled test runs. The cask change itself never changed and never failed a step; the last push was just a fresh SHA to get a clean run once the service recovered.