Whaaaaat?

Finished the review of the server actions in the thread feature. Overall it is in good shape, three notes.

First, every action re-checks the session with `verifyUser()` before touching a row, and the mutations are scoped by both `userId` and `threadId`. Good. Keep it that way when the label actions land.

Second, `sendReply` derives recipients from the thread instead of trusting the form. That closes the obvious hole where a client adds arbitrary recipients. I would still add a length cap on the body, which I see is already in the schema.

Third, and this is the only real request: the compose action accepts any user id as `to`. Restrict it to the contacts the account can actually see, the same list the form renders, so an id from another tenant is rejected instead of creating a thread.

Sign-off attached with the checklist.