feat(discord): add Discord Rich Presence support

[christopherjnelson]

Summary

Adds Discord Rich Presence support to the Linux shell using the IPC contract exposed by stremio-web.

Implementation

• Supports:
  • discord-connect
  • discord-disconnect
  • discord-set-activity
  • discord-clear-activity
  • outgoing discord-status
• Runs Discord socket operations on a dedicated worker thread.
• Uses a bounded Unix IPC transport with:
  • handshake and I/O timeouts
  • framed response parsing
  • a 1 MiB frame-size limit
  • nonce correlation
  • connection-liveness checks
  • socket-replacement detection
• Caches the current activity and restores it after Discord restarts.
• Clears cached state on explicit disconnect or activity clear.
• Does not log activity payloads, media titles, image URLs, or account data.

Flatpak

Adds narrow access for:

• native Discord: xdg-run/discord-ipc-0
• Discord Flatpak: xdg-run/app/com.discordapp.Discord:create
• Vesktop Flatpak: xdg-run/app/dev.vencord.Vesktop:create

No broad xdg-run access is granted.

The production Flathub manifest will require equivalent permissions when the feature is released.

Testing

• cargo fmt --all -- --check
• cargo clippy --all --no-deps -- -D warnings
• cargo test — 59 passed
• cargo build
• Flatpak manifest JSON validation
• Manual Flatpak-to-Flatpak testing on openSUSE

Manual testing covered:

• initial connection
• playback updates
• clearing presence
• disabling and re-enabling Rich Presence
• Discord shutdown detection
• Discord restart and cached activity replay

Additional cleanup

flatpak/build.sh now exits immediately when a command fails.

[tymmesyde]

Hi, thank you for your contribution, i'm closing this PR in favor of this one: #112

[christopherjnelson]

Thanks for taking a look and for getting Rich Presence merged.

One thing worth noting from my testing: discord-rich-presence does not continue reading responses or detect a replaced/dead IPC socket after the initial handshake. With both applications running as Flatpaks, quitting and reopening Discord left the client logically connected, and presence did not return until playback changed.

That was the reason my implementation added liveness detection and cached activity replay. I manually verified that flow against Discord restarts.

No need to reopen this PR, but I wanted to mention it in case the merged implementation shows the same restart behavior. I’d be happy to provide a smaller follow-up focused only on recovery if it becomes useful.