gate: Shorashim between a caller and a model, with the fringe and rebuke once (bishe'arecha step 4)

Devarim 6:9 / 11:20 — on your gates. POST /gate/anthropic/v1/messages and
POST /gate/openai/v1/chat/completions take the model's own request shape
under the caller's own upstream key (x-api-key, or Authorization with the
courtyard key in X-Shorashim-Key), forward it unchanged (OTP inets/ssl,
verify_peer; the Korban socket is serial, so the upstream call is made
in the Vav Pipeline and the reply enters as korban like every bedikah),
examine the reply with the request in hand — sources = the system prompt
and the user turns, query = the last user turn; the model's prior turns
are not sources — and deliver it with its fringe (Bamidbar 15:39): a
trailer on the last text block naming ref, verdict, the rules with their
verses and sentences; X-Shorashim-Bedikah / X-Shorashim-Verdict; a
`shorashim` object. A non-200 passes through as it came; a reply with
no text is not delivered; stream is refused.

Rebuke once (Vayikra 19:17; X-Shorashim-Rebuke: once): a lo_tov reply is
answered once more with the finding; the second reply is examined like
the first, its record carries rebukes: <first ref> (migration
20261007000002), and it is delivered marked with both. Never a third.

Manna: one api_calls_external per upstream call, gathered before any
call. Stateless: no conversation, no key kept; the log is the path class.
Gate.bearer accepts X-Shorashim-Key. Construction §3.10, Tamid §1.1,
KOHEN "Standing at the gate", bishearecha §I/§III/§VII marked built.
Elixir 592/0 (+14 gate tests incl. a real httpc round trip to a local
model double), L3 9/0.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

specs/shorashim_vayakhel.md

@@ -504,6 +504,65 @@ Errors: `{"status": "error", "code": PARSE_ERROR | INVALID_REQUEST | UNKNOWN_ACT
 
 ---
 
+### 3.10 The Gate — Vav Pipeline between a caller and a model (bishe'arecha §I, §III, §VII)
+
+**Protocol:** HTTPS outbound from the Vav Pipeline (OTP `inets`/`ssl`,
+the image's CA bundle, `verify_peer`), one request per pass; the
+request is the caller's own, in the model's own API shape, under the
+caller's own upstream key. Shorashim composes no korban here and holds
+no model key: it carries the request through, reads the reply as korban
+(§3.9), and delivers the reply with its fringe. The upstream call is
+made in the Vav Pipeline, not the Korban Processor, because the
+processor's socket serves one connection at a time with a 15 s call
+timeout and a model answers in up to 120 s; the reply still enters the
+processor as every bedikah does.
+
+```
+POST /gate/anthropic/v1/messages          body: an Anthropic Messages request, unchanged
+POST /gate/openai/v1/chat/completions     body: an OpenAI Chat Completions request, unchanged
+
+Headers:
+  Authorization: Bearer <courtyard key>     the gate (tablet 45) — or X-Shorashim-Key
+  x-api-key: <caller's Anthropic key>       forwarded, never stored, never logged
+  Authorization: Bearer <caller's OpenAI key>   when X-Shorashim-Key carries the courtyard key
+  anthropic-version: ...                    forwarded (default 2023-06-01)
+  X-Shorashim-Rebuke: once                  optional — hocheach tochiach (§VII)
+```
+
+**What the gate does with it** (`VavPipeline.Gate`):
+
+1. Forwards the body unchanged (the `stream` flag is refused: 422 — a
+   fringe needs the whole garment). The upstream's status and body are
+   returned verbatim on any non-200.
+2. Reads the reply's text (`content[].text` / `choices[0].message.content`)
+   and examines it: provenance from the upstream (`anthropic → claude`,
+   `openai → gpt`); **query** = the last user message's text; **sources**
+   = the system prompt (`system`), each user message's text and document
+   blocks (`user_1`, `user_2`, …) — the prior assistant turns are the
+   model's own output and are not sources. Nothing the caller did not
+   send is read.
+3. **The fringe** (§III): the delivered reply is the upstream's JSON with
+   (a) a trailer appended to its last text block —
+   `\n\n— shorashim <bedikah_ref>: <verdict>[ — <rule> (<verse>): "<sentence…>"…]`
+   — (b) headers `X-Shorashim-Bedikah`, `X-Shorashim-Verdict`, and (c) a
+   `shorashim` object: `{bedikah_ref, verdict, violations, anchors,
+   checks, rebuked?: {first_bedikah_ref, first_verdict}}`. The mark is
+   attached by the gate, never by the model.
+4. **Rebuke once** (§VII), when `X-Shorashim-Rebuke: once` and the first
+   reply is `lo_tov`: a second upstream request = the first body +
+   the first reply as an assistant turn + one user turn naming the
+   rules that fired, their verses and the sentences, asking for the
+   answer again without them. The second reply is examined like the
+   first (its `bedikot` row carries `rebukes: <first ref>`), and is the
+   one delivered — with both refs in the fringe. Never a third.
+5. Manna: one `api_calls_external` per upstream call, one compute unit per
+   examination; depleted → 503 MANNA_DEPLETED before any call is made.
+
+The gate is stateless: no conversation is kept, no key is kept, the
+log line is the path class and status (`NoTrackingLogger`). Upstream
+URLs are configured (`:gate_upstreams`) so the tests run against a local
+double; the production values are the vendors' endpoints.
+
 ## 4. SHEMEN HAMISHCHAH — Production Configuration
 
 *Mor d'ror chamesh me'ot, v'kinmon besem machatzito chamishim u'matayim...* — exact recipes.