[alexsohn1126]

This PR is stacked on #129975 (alexsohn/cw-2325-slack-out-of-credits-replies), which builds on #130271's shared out-of-credits notification. Review those first.

Today, when someone @mentions Seer in Slack, we start an agent run no matter how many Seer credits the org has left. If the org can't pay for it, the run fails partway through, or the user is left watching "is thinking..." with no explanation. A mention has no button we could have hidden ahead of time, so the only place to catch this is when the mention arrives.

Now, once the mention task knows who the user is and that they belong to the org, it checks whether the org can afford an agent chat message. If it can't, the task sends the shared out-of-credits notification, marked as "Seer never started", to that user as an ephemeral reply in the thread. It goes through the notification platform's Slack renderer, so it's the same message the autofix flow uses. The task then clears the thread's "is thinking..." status, records an out_of_seer_credits halt and returns. It skips everything else: reading the thread and linked messages, the inaccessible-links notice, and the agent run. If the reply fails to send, the status still gets cleared and no run starts.

The "is thinking..." status is set by the Slack webhook before the task is queued. I didn't move the credit check into the webhook, because that would put a billing call inside Slack's 3-second response window. So the status shows for a moment and then clears. Like the other halts in this task, the account-link and org-membership checks still run first, so an unlinked user gets the "link your account" prompt, not a credits message. While organizations:seer-credit-checks is off, the check always passes and nothing changes.

The shared message is the same whether or not Seer started, and its wording talks about continuing an Autofix run, which reads a bit off for a chat mention. If we want different copy here, it belongs in the shared notification, not this PR.

Fixes CW-2342

🤖 Generated with Claude Code

[linear-code]

CW-2342

[semgrep-code-getsentry]

Semgrep found 1 ssc-850b2fbf-06b4-4cff-aa0b-66db70e2c786 finding:

• static/app/utils/discover/eventView.spec.tsx
  • L31 - Triage

🟠 High severity issue identified in your code:

Risk: Affected versions of decode-uri-component are vulnerable to Inefficient Algorithmic Complexity / Uncontrolled Resource Consumption. decodeUriComponent() falls back to a custom decoder on malformed input that performs one full-string regex replacement per distinct percent-encoded run, giving quadratic time complexity. The function is reached directly, or indirectly through query-string (parse(), parseUrl(), stringifyUrl(), pick(), exclude()), which decodes every key and value with decode-uri-component. An attacker can send input with many distinct percent-encoded runs and a malformed sequence (e.g. a trailing "%zz") to block the Node.js event loop and cause a denial of service.

Fix: Upgrade this library to at least version 0.5.1 at sentry/pnpm-lock.yaml:5876.

Reference(s): https://euvd.enisa.europa.eu/vulnerability/EUVD-2026-112471, GHSA-qr28-fpjm-wq7f, CVE-2026-118664