Implement wallet connections service-detail modal CRUD flow

docs/wallet-connections.md

@@ -11,6 +11,21 @@ Use the existing Hub service tile flow:
 3. Complete existing port/domain/DDNS/rebuild flow (80/TCP and 443/TCP).
 4. Reopen tile and manage connections.
 
+## Service-detail modal UX (implemented)
+
+Wallet management now runs inside the existing **Wallet Connections** service-detail modal with dedicated states:
+
+1. **Empty state**: no wallets yet, with create action.
+2. **Create form**: name, alias, access preset, optional spend limit.
+3. **Created/secret state**: one-time pairing secret (URI + QR when available) shown with explicit "save now" warning.
+4. **Wallet list state**: per-wallet actions for verify/test, drain, and delete.
+
+Guardrails in modal flow:
+
+- Action buttons are disabled while API requests are in flight.
+- Destructive actions (drain/delete) require user confirmation.
+- API errors are surfaced inline in the modal state.
+
 Node role behavior is unchanged: Node onboarding still skips global domain/port setup, and the `lightning` domain is configured on demand through feature enablement.
 
 ## Architecture
@@ -25,6 +40,7 @@ Security invariants:
 - LNURL callback/discovery are exposed only through Caddy on 80/443.
 - Management APIs are authenticated and remain under `/api/nwc/`.
 - Pairing secrets are returned only on create responses.
+- Pairing secret QR data is generated only for create responses and is not rehydrated via wallet list APIs.
 - Invoice attribution enforces wallet isolation with app-id checks.
 
 ## Domain and runtime files