backend-validation

# Backend Validation For CLI-driven validation of backends behind OIDC auth. Deliberately tool-specific — Hurl, websocat, oauth2c. If the project has already picked Bruno/Postman/Insomnia, stop and use those instead; don't fork the tooling. ## Framing before you test Before picking flags and writing assertions, work the change as a thinking exercise — the tools come after. 1. **What feature does this change represent?** State it as a user-visible effect, not a function signature. If you can't state it that way, you don't yet know what to validate. 2. **What does success look like?** Be concrete — "a new session appears with status 'active' within 2s" beats "it works." Vague success criteria produce vague tests. 3. **Validate in two passes.** User-lens: drive the feature as a user would (for backend, that often means exercising the endpoints the UI calls, in the order and shape the UI sends them). System-lens: verify the system did the right thing underneath — status codes, DB rows, WS events, logs clean. Bugs hide in exactly one of these; running both catches them. 4. **Check 2–3 adjacent paths.** A `/sessions POST` probably affects the `/sessions/mine` listing, any subscribed realtime channel, caches. Don't attempt full regression — pick nearby behaviors that would obviously break. 5. **Cover realistic failure modes** (missing auth, invalid body, not-found, race on a shared resource), not exhaustive ones. One test per failure class beats ten happy-path tests. 6. **Skip w...