feat(temp-vc): spawn failure handling: hub chat message, last failure per hub, Sentry once per streak

[SyniRon]

Closes #290. Spec: #285.

What changed

A failed create sends one message in the hub channel's text chat that mentions the member alone. The area is full when Discord reports the category or guild cap. Otherwise the failure has been reported. No DM, no disconnect, and the bot never deletes the message. A create that succeeds and a move-into that fails is one failure: the new channel goes through the empty-channel delete path, and the message goes out only when the runtime's own occupancy map still has the member in the hub.

The runtime keeps each hub's last spawn failure in memory as time and SpawnFailureCause. LastSpawnFailure(hubID) is the reader for the panel. The next successful spawn from that hub clears it. The store writes nothing for a failure. A hub with no category records no category, makes no API call and never reaches Sentry.

Create failures Discord returned capture once per streak per hub: the cap, 403, 429, 5xx, transport. The first failure captures and the next capture waits for a successful spawn from that hub. Delete failures follow the same shape for 403, 5xx and transport. A 429 on delete is a WARN line only. Unknown Channel stays quiet cleanup. commands/temp_vc_errors.go classifies the spawned channel paths on its own. The warden classifier is untouched, so its not-found branch still pages on the warden paths.

TempVCManager grows ChannelMessageSendComplex. The adapter passes WithRetryOnRatelimit(false) like every other call.

Two readings to confirm

1. A hub with no category sends no message to the member. The spec's lifecycle bullet and the ticket both say "makes no API call". Story 28 reads the other way. Story 31 calls the refusal "a log line and a panel note". If story 28 should win, the change is one call in the no-category branch and one test expectation.
2. The delete-side streak ends on a successful delete of one of that hub's channels, not on a spawn. The spec says "the same rule as create". With the literal reading, working spawns and broken deletes would page once per leave. The two readings agree in every other case.

For the smoke test

The category cap has no Discord error code of its own. The classifier reads a 400 50035 body for CHANNEL_PARENT_MAX_CHANNELS under parent_id. That shape comes from Discord's documented form-error format, not from a live refusal. Fill a category to 50 on the test guild and check the member gets the "full" text. A failed create on a hub whose text chat the bot cannot post in is the other path worth one join.

Tests

Eight new tests at the seams a seam-sniffer review approved: the fake manager, the captureError seam, store.NewFake() and a pinned clock. They assert the message's channel, allowed mentions and user ID, that the cap and generic texts are two texts under one fixture, the move-into cases, the last failure read back, capture counts over a streak and after a success, and the delete classification table. No test asserts log wording or message copy.

CI gate run locally: lint, tidy, race tests with coverage floors (commands 93.4%), build.

Docs

CLAUDE.md's runtime section and the #278 row of docs/temp-vc-decisions.md record the delete classification and the category cap shape.