fix(chat): fetch public keys per user

[boboliu-1010]

Summary

• fetch participant public keys through GET /2/users/:id/public_keys instead of the batch endpoint
• preserve the owning user_id on each returned key
• identify the specific user when a key lookup fails and avoid returning partial results
• add regression coverage for the per-user routes and failure behavior

Why

Some production X apps can access the per-user public-key endpoint but receive client-not-enrolled from GET /2/users/public_keys?ids=..., even when the batch contains a single user. That prevents xurl chat read from loading signing keys and verifying messages.

Using the per-user route trades one batch request for one request per participant, but works across apps that are not enrolled for the batch endpoint and preserves the same result shape for callers.

Verification

• go test ./api
• go test ./...
• go vet ./...

Fixes #94

[vkurilyak]

Big fan of xurl, thanks for building and maintaining it.

Confirming the same behavior on a matching setup, and +1 for the per-user route.

Environment: macOS arm64, xurl v1.3.1, OAuth 2.0 user context, X app on Pay-per-use, chat keys restored via Juicebox. xurl whoami and xurl chat conversations work.

Repro before the fix:

• xurl chat read @handle --no-mark-read logs could not fetch public keys ... client-not-enrolled and cannot decrypt messages.
• GET /2/users/public_keys?ids=<single id> returns client-not-enrolled for this app, even with one id in the batch.
• GET /2/users/<id>/public_keys returns valid keys for both my account and the counterparty with the same app and token.

Verified this PR branch locally: built with CGO_ENABLED=1, go test ./api passes, and chat read now decrypts and verifies live 1:1 threads, including a conversation that includes a KeyChange event. Five consecutive reads on the same thread decrypted correctly. Thanks for the fix.

[boboliu-1010]

Thanks for the detailed independent verification — especially testing a live thread with a KeyChange event and repeated reads. That confirms the per-user route fixes the issue in another production setup. No additional changes are planned from my side; this is ready for maintainer review.