feat: Discord slash command handling via HTTP interactions

[cipher416]

Problem

Discord slash command interactions (APPLICATION_COMMAND) were acknowledged but never forwarded to onSlashCommand, so handlers were never invoked when using HTTP Interactions in the Discord adapter (#131).

Solution

Handle APPLICATION_COMMAND interactions by constructing a slash command event and calling processSlashCommand. Persist the interaction token in state so deferred responses can be patched via the interaction webhook, then fall back to normal channel messaging if needed.

Changes

1. Implement handleSlashCommandInteraction to validate inputs, build the event, store the interaction token, and invoke processSlashCommand.
2. Persist interaction tokens with a 15-minute TTL and use them to PATCH the original deferred response before posting to the channel.
3. Update tests to cover slash command processing and event shape.

Testing

Verified end-to-end with a real Discord bot + ngrok tunnel — /help and /echo both fire handlers and resolve the deferred "thinking" response.

2026-03-02.14-21-24.mp4

Responses with file attachments:

2026-03-02.15-06-37.mp4

[vercel]

@cipher416 is attempting to deploy a commit to the Vercel Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

Slash command responses with file attachments bypass the interaction token PATCH logic, leaving the "thinking" indicator unresolved and posting a regular channel message instead.

[cipher416]

closing this as this is a duplicate of this PR:
#152

[PClmnt]

closing this as this is a duplicate of this PR:

You didn't have to close :) We could have just waited and seen what the maintainers preferred!

[cipher416]

closing this as this is a duplicate of this PR:

You didn't have to close :) We could have just waited and seen what the maintainers preferred!

@PClmnt

No worries! After reviewing your implementation I realized the AsyncLocalStorage approach is fundamentally better than what I had (storing the interaction token in shared state with a TTL key):

• No race condition — each request gets its own isolated context, so concurrent slash commands in the same channel can't overwrite each other's tokens
• Multi-reply support — your initialResponseSent flag correctly PATCHes @original for the first reply and POSTs a
  followup for subsequent ones. Mine always tried to PATCH, which would break on the second reply
• No cleanup needed — the context is GC'd when the request finishes, no TTL or explicit state.delete() required

One thing I noticed while testing: file attachment responses also need to go through the interaction webhook path
(multipart PATCH/POST). Without that, /attach-style commands leave the "thinking" spinner unresolved. I added a couple of tests for that (on this closed PR), happy to contribute them in your PR if useful.