fix: Switch RSVP rkeys from deterministic SHA-256 hash to TIDs

[tompscanlan]

Summary

RSVP records published to the PDS use a truncated SHA-256 hex hash as the rkey (e.g., b1655b1019d66) instead of a proper TID (Timestamp Identifier). This looks non-standard to other AT Protocol clients.

Background

AT Protocol records use TIDs as rkeys — these are timestamp-based identifiers that sort chronologically. The current code uses a custom hash for implicit idempotency (same event always gets the same rkey), but this is redundant since OpenMeet already stores atprotoRkey on the EventAttendeesEntity.

Current behavior

In src/bluesky/bluesky-rsvp.service.ts:

• generateRsvpRkey() hashes the event URI with SHA-256 and takes the first 13 hex chars
• Always uses putRecord with this deterministic rkey

Proposed fix

In bluesky-rsvp.service.ts:createRsvp():

• New RSVPs (no existing atprotoRkey): Use createRecord instead of putRecord. The PDS assigns a proper TID. Extract the rkey from the returned URI and store it.
• Updated RSVPs (existing atprotoRkey): Use putRecord with the stored rkey.
• Delete the generateRsvpRkey() method entirely.

Files to change

• src/bluesky/bluesky-rsvp.service.ts — main logic change
• src/bluesky/bluesky-rsvp.service.spec.ts — update tests

Context

• AT Protocol TID spec: https://atproto.com/specs/record-key#record-key-type-tid
• The @atproto/common-web package provides a TID.nextStr() helper if needed, but createRecord handles TID generation server-side