[feature] Epic: Add signed challenge flow for automatic joins

[marwannettour]

Summary

Implement a signed challenge-response flow for automatic trusted-device joins.

The goal is to prove that the joining client possesses the private key associated with its already trusted public key before any automatic session join is accepted.

Context

The security study recommends challenge-response instead of long-lived bearer tokens. This aligns with ByteSync's existing RSA identity model and avoids making a stolen persistent token sufficient for auto-join.

Proposed scope

• Add a nonce/challenge generation flow for automatic joins.
• Bind challenges to session, requester, target member, timestamp, and purpose.
• Require the requester to sign the challenge with its local private key.
• Verify the signature with the already trusted public key.
• Reject expired, replayed, malformed, or mismatched challenges.
• Integrate the challenge result with trusted-device grant validation.
• Preserve the existing encrypted session password and AES key exchange guarantees.

Out of scope

• Replacing all existing manual join validation.
• Allowing auto-join for clients that are not already mutually trusted.
• Storing long-lived passwordless bearer secrets.

Acceptance criteria

• A challenge can be issued for an automatic join request.
• The requester signs the challenge with its device private key.
• The validator or server-side flow verifies the signature against the trusted public key.
• Challenges expire quickly and cannot be replayed.
• The join is rejected when the grant is missing, expired, revoked, or bound to a different key.
• Audit-friendly rejection reasons are available for UI, CLI, and logs.
• Tests cover happy path, invalid signature, replay, expiration, wrong client, wrong session, revoked grant, and key mismatch.

Security position

Automatic join must be passwordless from the user's perspective, not trustless from ByteSync's perspective.