Fix auth and SSRF vulns

[jmecom]

Summary

This PR fixes a set of auth and SSRF weaknesses in the relay and desktop client.

The relay changes close authorization gaps around personal workflows, stop trusting request forwarding headers when verifying NIP-98 token mints, cut off live WebSocket subscriptions immediately after channel membership is revoked, and block IPv6 unspecified addresses in workflow webhook SSRF checks. The desktop changes harden authenticated Tauri request construction so attacker-controlled IDs cannot be interpreted as raw path traversal on the relay origin.

Explanation of vulns

• Personal workflows were missing owner checks on runs and trigger, so another authenticated user who learned a personal workflow UUID could trigger it and read run history.
• POST /api/tokens rebuilt the signed NIP-98 URL from request headers, so a captured bootstrap mint request could be replayed to a different relay if that relay trusted attacker-supplied forwarded host/proto values.
• Channel membership revocation only updated the database; it did not evict existing WebSocket subscriptions. A removed user who stayed connected could continue receiving new channel events until reconnect.
• Workflow webhook SSRF checks blocked 0.0.0.0 but not IPv6 unspecified ::, which left a path to target localhost-bound IPv6 services via http://[::]:... and read the response back through workflow run history.
• Several Tauri commands interpolated untrusted IDs directly into REST paths. In a WebView/IPC compromise, that let an attacker use .. segments to make authenticated same-origin requests to unintended relay routes.

What changed

• Personal workflows now consistently enforce owner-only access for:
  • GET /api/workflows/:id/runs
  • POST /api/workflows/:id/trigger
• POST /api/tokens now verifies NIP-98 signatures against the configured relay URL instead of X-Forwarded-* / Host.
• Channel removals now evict existing live channel subscriptions for the removed user, so revoked access takes effect immediately for active sockets.
• Workflow webhook SSRF validation now blocks IPv6 unspecified :: / [::] in both shared IP classification and workflow URL validation.
• Desktop Tauri commands now build relay API paths from encoded path segments via a shared helper, and authenticated request builders reject raw . / .. traversal segments before sending same-origin requests.

[wesbillman]

@jmecom Thanks for this PR, is this good to merged now that it's approved?

[jmecom]

@jmecom Thanks for this PR, is this good to merged now that it's approved?

Yes! I don't think I can merge though.