…ient poll failures

Sixtyfour's block param mapper wrote `result.struct = params.leadStruct`
unconditionally. On the agent path the model supplies the *tool* param name
(`struct`), not the subBlock name (`leadStruct`), so the mapper's return —
which is overlaid on the model's arguments — set the required `struct` to
`undefined` and the call went out without it. Same for `enrich_company`.
Every rename is now guarded on its source being present; a configured block
value still wins because it is present.

Enrow's find/verify polls threw on any non-2xx, so a single transient 5xx
killed a job that was still running. Both polls now share `poll.ts`, which
retries 429 and 5xx up to three times for the whole poll using
`backoffWithJitter`/`parseRetryAfter`, charging the backoff against the
existing 120s budget rather than extending it. Non-transient statuses still
fail immediately.

Also corrects the `ENROW_CREDIT_USD` docblock, which cited a $24/2,000-credit
Starter plan that does not exist on Enrow's price list. The rate itself is
left alone — see the PR body.

…e abandoned bodies

Review follow-ups on the polling helper.

The budget was accounted purely in intended sleep time, which `await fetch`
never advances — a hung socket outlived the 120s window entirely. The loop now
also carries a wall-clock deadline and caps each request with
`AbortSignal.timeout(remaining)`, so a stalled connection is aborted at the
window rather than after it. An abort surfaces as the window message; any other
transport failure is rethrown unchanged.

A transient response late in the window added the prospective backoff to
`elapsed` and broke before sleeping it, ending polling up to 15s early and
abandoning a job that was still running. The backoff is now clamped to the
remaining budget and always slept, so the loop waits out the full window.

202 and to-be-retried responses had their bodies abandoned mid-stream, holding
the socket out of the pool for the rest of the poll. Both paths now cancel the
body before continuing.

Tests: the Retry-After case now asserts the delay it claims to prove rather
than only that a 429 is retried — dropping `readRetryAfterMs` from the backoff
call turns it red. Added coverage for body release, the per-request abort
signal, abort-to-window-message, transport-error passthrough, and the
full-window wait.

Also splits the finder and verifier doc citations on ENROW_CREDIT_USD; the
0.25-credit claim was hanging off the finder endpoint. The rate itself is
unchanged.

The backoff was clamped against `MAX_POLL_TIME_MS - elapsed`, but `elapsed`
charges nothing for time spent inside `await fetch`. With slow polls the real
clock runs ahead of it, so that term overstates the remainder and a wait sized
against it lands past the deadline — up to 15s past, on a capped Retry-After.
The poll interval had the same defect at a smaller scale, worth up to 3s.

Both waits now go through one `remainingBudgetMs()` helper returning whichever
of the two budgets has less left, so there is a single clamp rule rather than
two that disagree. The request timeout keeps using the wall clock directly,
which is the only bound that means anything to an in-flight socket.

The new test drives a stubbed clock that the mocked `sleep` and the `fetch`
stub both advance, so the second poll completes past the deadline while
`elapsed` still believes 99s remain. It asserts the backoff is dropped rather
than clamped to that phantom budget, and that no sleep begins after the
deadline. Reverting the clamp to `MAX_POLL_TIME_MS - elapsed` turns it red.

The comment justifying `requestsPerMinute: 60` claimed "Enrow rate limit
is ~50 req/s". Enrow documents 10 req/s per API key on every POST
endpoint (https://docs.enrow.io/rate-limits) — 600/min, not 3,000.

The cap itself stays correct: 60/min is conservative against either
figure, and the reason for it (not bursting into the limit while a job
polls) is unchanged. Only the number a future reader would size the cap
against was wrong — the same false-citation class this branch already
fixes on ENROW_CREDIT_USD.

`isTransientStatus` checked `status >= 500`, so a 6xx would have been
retried as if it were a server error. A status is a three-digit field:
the `Response` constructor refuses anything outside 200-599, but a status
parsed off the wire is not built that way, so a misbehaving intermediary
can surface one. A 6xx is not something a later poll recovers from, so it
now fails fast with the status attached rather than burning the poll's
retry budget on it.

Test asserts a single call for a 600; verified red against the old
predicate.

The guard added earlier tested `!== undefined`, which is not enough. The
serializer stores every untouched subBlock as `params[id] ?? null`, so an
unfilled field arrives as `null` and a cleared one as `''` — both pass
`!== undefined` and get written straight over the model's tool-call
argument. `struct: null` reaches the tool as an invalid required param;
`struct: ''` fails its `JSON.parse` with "struct must be valid JSON".

Replaced with a `present()` helper testing all three, which is the same
guard `trigger_dev`'s `scoped()` and the `enrow` mapper already use.
Applied to the switches too, so `Boolean(null)` can no longer force
`false` over a `true` the model sent, while a switch the user actually
turned off still forwards as `false`.

Also corrects what the hosted-key rate limit claims to do. The limiter is
consulted once per tool execution, not per outbound request, so it never
throttled the poll loop's GETs and the old comment's "avoid bursting into
the limit during polling" was wrong. It is accurate as a per-workspace
execution cap: each execution issues exactly one POST, and Enrow's
documented 10 req/s applies to POST endpoints only, so 60/min sits an
order of magnitude under the ceiling.

Four tests, each verified red against the weaker guard.

`AbortSignal.timeout` fires against the whole exchange, so a 200 whose
headers arrive just inside the window can still have its body aborted
mid-read. That rejection surfaces at `response.json()`, outside the
try/catch guarding the `fetch`, so the raw `TimeoutError` escaped —
naming neither Enrow nor the window it exhausted. It now takes the same
abort path and ends the poll with this module's own window error.

The error-body read gets the same treatment from the other direction: a
body that cannot be read no longer replaces a terminal failure with an
unrelated transport error. The status is the diagnostic and it now
survives, with `<unreadable body>` standing in for the text.

Both tests verified red against the unguarded reads.

A throw out of `postProcess` never reaches the user. `executeTool` wraps
every `postProcess` call in a catch that logs and then restores the
pre-`postProcess` result — which for these tools is the *submit*
response: `success: true` with every result field null. So a poll that
timed out, exhausted its retries, or hit a terminal status was reported
as a successful lookup that simply found nothing.

Both Enrow tools now catch the poll failure and return it as
`success: false` with the message and the job id preserved. Returning
rather than throwing also stops the hosted-key cost hook, which is gated
on `finalResult.success`, from billing an execution that produced no
result.

The eleven existing failure-path tests asserted the throwing contract and
were bypassing the executor wrapper, which is exactly why this went
unnoticed; they now assert the returned failure. One test pins the whole
shape — `success: false`, the error, and the null-field output — so the
silent-success regression cannot come back.

Also corrects the rate-limit comment again: `executeTool` retries an
upstream 429/503 and can re-acquire a key, so an admitted execution can
issue more than one POST. The 60/min figure is an admission cap, and even
at that retry ceiling it stays an order of magnitude under Enrow's
documented 600/min.