Deploy strata-qa as a container-image Lambda behind a Function URL

[baonguyenNava]

What

Deploys the strata-qa docs Q&A CLI as a container-image AWS Lambda behind an IAM-authed Function URL: a question goes in over HTTPS, the existing QaResult JSON comes back.

Relates to #30

How

Two thin modules over the already-tested runQa() seam, with no new QA logic. src/lambda/core.ts exposes an HTTP-free handleQuestion(job, seam, config), the seam a future Slack dispatcher calls after its 3-second ACK. src/lambda/handler.ts adapts it to the Function URL: request validation (method, base64, 2000-char question cap, model allowlist), exit-code to HTTP mapping (refusals are 200; auth/docs 500, model/parse/transport 502, timeout 504), Secrets Manager key loading with rotation-safe retry, and the two wall-clock guards below.

Timeouts are bounded twice, per call and per invocation. AGENT_TIMEOUT_MS bounds each agent call, but runQa can make two (retrieval, then a tool-less repair) and the handler retries once on auth, so per-call bounds do not sum to a request bound — at 90s per call one request could spend 180s against a Lambda timeout of 120. The handler therefore also derives a whole-invocation budget from the Lambda context's remaining time and bounds the entire run against it. That guarantee matters less for the lost answer than for the recycle below: a Lambda hard-kill is the one path that returns no 504 and never reaches recycle(), so it would leave the orphaned agent alive in exactly the container the recycle exists to replace. Bounding the invocation from the context rather than tightening deploy.sh's arithmetic keeps the guarantee independent of how many bounded calls runQa happens to make.

The recycle exists because withTimeout races but never cancels the agent; on Lambda's freeze/thaw the orphan would resume inside the next invocation, so the handler poisons the container and lets Lambda replace it.

Docs, the CLI, and the Linux @cursor/sdk binary are baked into the image at build time from the repo-root context. deploy.sh scripts ECR, Secrets Manager, IAM, the function (reserved concurrency 3 as a spend ceiling), and the Function URL. Writing the secret is opt-in after the first deploy (ROTATE_SECRET=1), so a redeploy from a shell holding a stale CURSOR_API_KEY cannot overwrite a working key — a live hazard here, not a hypothetical one.

One pre-existing file changed beyond a moved constant: log.ts now swallows filesystem errors to stderr, because runQa logs on its success path and Lambda's filesystem is read-only outside /tmp, so a failed log write must not destroy a paid-for answer.

Test plan

• npm test: 160/160 vitest units pass (67 Lambda tests, all against the existing AgentSeam fakes, no live model calls); npm run build and tsc --noEmit compile clean; python -m pytest 65/65; lint_manifest, lint_docs, and build_graph each print their _OK sentinel with no resulting graph diff.
• Gate 1 (SDK feasibility): the arm64 image runs plan-mode retrieval with a read-only root filesystem and HOME=/tmp, returning a grounded answer in 12.1s at ~117 MiB peak RSS; docsVersion correctly falls back to the sha256: hash since the image has no .git.
• Gate 2 (orphan/recycle) via the Runtime Interface Emulator: a forced 3s timeout returned a complete 504 body with the requestId echoed, the poisoned container exited, and the post-reset invocation was clean with zero log chatter from the orphaned run.
• RIE smoke: happy path 200 answered (~10.5s), bad body 400, one structured CloudWatch log line per invocation carrying gitSha, no EROFS anywhere.
• deploy.sh against a live AWS account. Syntax-checked with bash -n; the live deploy and the SigV4 smoke have not been run, so the whole script is unexercised end to end.

Notes for reviewers

Stacked on #38 (baonguyenNava/30-strata-qa-cli), which adds the CLI this wraps, so merge that first; only the 16 commits after that branch point are new here.

@cursor/sdk stays pinned at exactly 1.0.24: plan-mode is the only runtime containment for attacker-supplied questions, and a bump requires re-running the PWNED.txt probe from NOTES.md.

Invoking the Function URL needs lambda:InvokeFunctionUrl in the caller's own IAM policy. deploy.sh attaches no resource policy, so without it the URL answers 403 before the handler ever runs — easy to mistake for a broken deploy on a first smoke test.

The poisoned flag sacrifices one invocation after each timeout by design; timeouts are rare (9-14s typical answers against a 90s bound). The fallback if it ever proves unreliable in production — fork a worker per invocation and SIGKILL it on timeout, true cancellation for a ~100ms spawn — is described inline in handler.ts beside the recycle.

Two known deviations from the ideal, both cheap to live with for this slice. The auth-retry path emits a second structured log line, so "one line per invocation" holds everywhere except a retry. And replyTo is accepted, type-checked, and then ignored; it is reserved for the async dispatcher and will need URL allowlisting rather than a type check once something actually fetches it.

Known follow-up: /tmp/.cursor (SDK session state) grows ~3 MB per answered invocation on a warm container, roughly 330 invocations to the 1 GB tmpfs cap, so a post-invocation cleanup is a candidate for the Slack slice.