Add response access and stop mangling non-HTTP request payloads

Stored responses were unreachable from the CLI even though the model
layer has had list/get/delete all along. After a send, an agent could
only see the body it just streamed: no status, no timing, no history.
`yaak response list|show|body|delete` closes that. `show` and `body`
accept a request ID as shorthand for its most recent response, which is
the common case, and `show` returns status, reason, timing, headers, the
final URL, and any transport error as JSON.

`request create` also accepted payloads for request types it cannot
create. A gRPC-shaped payload deserialized into an HttpRequest with the
unknown fields dropped, so the gRPC method name landed in `method`,
`service` vanished, and the result looked like a successful create. It
now rejects a non-`http_request` `model`, and any field that is not part
of the HTTP request schema, pointing at the app instead. `request update`
had the same silent-drop behavior and gets the same check.

The skill now points at `response show` rather than teaching agents to
grep verbose send output for the status line.

crates-cli/yaak-cli/skills/use-yaak/SKILL.md

@@ -110,18 +110,26 @@ committed `yaak export` plus `--data-dir ./.yaak` gives a runnable suite in CI.
 
 ## Reading results
 
-A plain send writes only the response body to stdout. Add `-v` for the request
-and response metadata, where lines are prefixed `*`, `>`, and `<`:
+A plain send writes only the response body to stdout. Yaak also stores every
+response, so the reliable way to see what happened is to ask afterwards rather
+than to parse the send output:
 
 ```bash
-yaak -v request send rq_abc123 2>&1 | grep '^< HTTP'
+yaak response show rq_abc123     # latest response for a request, as JSON
+yaak response list rq_abc123     # its history, newest first
+yaak response body rq_abc123     # just the body
 ```
 
+`response show` gives status, reason, timing, headers, the final URL, and any
+transport error. Pass a response ID for a specific one. `-v` on a send prints
+the same information live, prefixed `*`, `>`, and `<`, but interleaves it with
+the body on stdout, so prefer `response show` when you need to act on the result.
+
 Exit code 1 means the send did not complete: an unresolved template variable, an
 unreachable host, a TLS failure. **HTTP error statuses are not failures.** Like
 `curl`, a 404 or 500 exits 0, and a folder of requests that all return 500
 reports success. Never tell the user an API is healthy based on a clean exit;
-check the status yourself with `-v`.
+check the status.
 
 ## Execution rules