docs: relay-transport (nostrclient) section + dependency note

Document the in-process nostrclient publish/subscribe path, the public-vs-
encrypted split (encrypted events await bunker/server-signing), and the
soft runtime dependency on the nostrclient extension.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_019VUQCfdqiLSsFS2jcGnaFD

README.md

@@ -4,9 +4,18 @@ Nostr-native room rentals for LNbits — an "Airbnb for the castle". List
 rooms, take booking requests, arbitrate availability, and settle stays over
 Lightning, with Nostr as the interop layer.
 
-> **Status:** design sketch + scaffold. Data model, migrations, availability
-> arbiter, REST surface, and Nostr event model are in place; relay plumbing,
-> FX/invoice wiring, and the guest UI are stubbed with `TODO(...)` markers.
+> **Status:** functional prototype. Data model, migrations, availability
+> arbiter (atomic hold), FX + invoice + settlement, the REST + kind-21000 RPC
+> doors, and the nostrclient relay layer (publish + availability queries) are
+> in place and tested. The guest UI and encrypted-event delivery pre-bunker
+> are the remaining gaps.
+>
+> **Soft dependency:** publishing/subscribing to relays uses the **nostrclient**
+> extension (imported in-process). Install + activate it to reach relays; if
+> absent, the booking flow still works over HTTP/RPC and relay publish is
+> skipped with a logged warning. Encrypted events (reservation `30078`, check-in
+> DMs) additionally need a bunker/server-signing signer (lnbits #18); on a
+> LocalSigner they soft-fail until then.
 
 ## Why not just reuse an existing NIP?