The autouse `verify_runner_saw_all_boxes` fixture shells out to
`journalctl -u boxlite-runner`, which only resolves on a host where the
runner systemd service is installed (the current self-hosted KVM
runner). When the e2e suite migrates to a GitHub-hosted runner pointing
at a remote stack (Tokyo Api/Runner deployment), journalctl returns
zero hits and every box-creating test fails on the path-verify assert
even though the box actually reached the remote runner.

Setting BOXLITE_E2E_SKIP_PATH_VERIFY=1 short-circuits the fixture
(yield-and-return before the journalctl probe). The cloud-CI workflow
will set this; the self-hosted KVM job keeps the guard.

The FFI-bypass risk this guard defends against doesn't apply on a stock
GHA runner — no KVM means libkrun can't start a VM, so a silent
fallback would surface as a hard error, not as a passing-but-wrong
test. Losing the guard in that environment loses no real safety net.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Adds scripts/ci/setup-e2e-cloud-oidc.sh — sibling to setup-ci-runner.sh
but for the cloud-stack regression suite (`.github/workflows/e2e-cloud.yml`,
added in the next commit).

A separate IAM role (`boxlite-e2e-cloud-github-actions`) is needed
because the existing `boxlite-e2e-github-actions` role is tuned for
the us-east-1 KVM-runner provisioning path. Cloud e2e against the
ap-northeast-1 Tokyo stack needs an orthogonal permission set — ECR
push, ECS update-service + execute-command, SSM send-command to a
specific runner EC2, S3 builds/ artifact upload, parameter-store
reads. Splitting the roles keeps each one auditable under least-privilege.

Scoping:
- Trust policy `sub` is an enumerated allowlist (main pushes,
  pull_request, environment:e2e-cloud) — a stray workflow added on
  a feature branch can't assume the role.
- ssm:SendCommand is gated by `ssm:resourceTag/Name=boxlite-runner`
  so the role can only shell the runner EC2.
- ecs:UpdateService restricted to boxlite-e2e-ci-*/Api service ARN;
  ecs:ExecuteCommand to boxlite-e2e-ci-*/* task ARNs.
- Resource wildcards remaining (ecr:GetAuthorizationToken, ssmmessages:*,
  ecs:Describe*, elbv2:Describe*) are forced by AWS not supporting
  resource-level scoping for those actions.

Sources scripts/common.sh for the shared log helpers so this script's
output matches setup-ci-runner.sh.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous e2e-stack.yml bootstrapped a full local stack (postgres,
redis, docker registry, boxlite-runner systemd, boxlite-api) inside a
self-hosted KVM runner per PR — slow to maintain (bootstrap drift,
KVM runner contention) and only covers self-bootstrap state.

This workflow keeps the same 3-job structure introduced by PR #680
(changes / e2e / e2e-gate) so the `E2E gate (required)` branch
protection check is unchanged, but replaces the `e2e` job:

- runs-on: ubuntu-latest (no /dev/kvm needed)
- authenticates to AWS via OIDC using the new
  boxlite-e2e-cloud-github-actions role
- builds the Api container image + boxlite-runner musl binary from
  this checkout
- deploys to the always-on Tokyo stack: rolling-updates the Api ECS
  service to the new image and SSM-replaces the runner EC2's binary
- initialises the admin-org sandbox quota row in RDS via ECS Exec into
  the Api task (DB_PASSWORD stays in container env — never in the
  SSM command body)
- builds & installs the Python SDK from this checkout (path_prefix
  and other source-tree additions land ahead of the PyPI release)
- runs `pytest scripts/test/e2e/cases/` against http://<api-lb>/api
  with BOXLITE_E2E_SKIP_PATH_VERIFY=1 (journalctl-based path verify
  doesn't reach the remote runner)
- on failure, dumps Api CloudWatch logs + boxlite-runner journalctl

Concurrency uses a constant group (`e2e-cloud-shared`) because every
run — push + PR — competes for the same singleton Tokyo stack. Per-ref
grouping would let two PRs interleave ECS rolling updates.

Resource discovery (cluster id, LB DNS, runner instance id, S3
bucket, ECR repo) is by-pattern at workflow start, with a strict
count=1 assertion so an orphaned `ApiLoadBalancer-*` from a partial
SST teardown fails the job loudly instead of silently binding to
the wrong target. SSM agent ping-status is verified before the
runner update step to fail fast on a dead agent.

Adversarial review (multiple lenses) caught and this commit addresses:
- credentials.toml written via printf rather than unquoted heredoc
  so a `$` inside the admin key can't be shell-expanded; ADMIN_KEY
  immediately registered via `::add-mask::`
- ECS execute-command output is captured and grepped for the
  expected SELECT row (Session Manager exit-code propagation has
  historically been unreliable through --interactive without a tty)
- `wait services-stable` is followed by ALB target-health polling
  AND a /api/health curl with retry — services-stable alone races
  the LB health check
- pytest wrapped in `timeout 35m` plus
  `--timeout=180 --timeout-method=thread` so a hung VM doesn't burn
  the 45-min job timeout before `Collect logs on failure` runs
- Rust build cached via Swatinem/rust-cache@v2 so repeat PR builds
  are incremental
- both actions/checkout occurrences bumped to @v5 to match the
  newer workflows in the repo

Known limits (TODO/follow-up, not blocking):
- boxlite-runner has no documented in-flight drain; restart drops
  any request landing during the swap window. Acceptable for e2e
  (no concurrent users) but a production-grade rollout would need
  a runner-side graceful drain.
- No post-run restore of `main` HEAD on the Tokyo stack: the stack
  is left running the last e2e-cloud run's image. Console inspection
  of `api-<sha>` identifies the running revision.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

- Add `e2e-cloud.yml` section to .github/workflows/README.md mirroring
  the structure of the e2e-test.yml section (Why / Architecture /
  Triggers / Cost / Authentication / Required variables / Required
  AWS resources / Concurrency / Stack state).
- Side-by-side table contrasts the two e2e workflows' IAM roles,
  regions, and scopes so future maintainers can tell at a glance why
  both exist.
- Fix line 198 which referenced `scripts/ci/setup-aws-oidc.sh` — that
  filename does not exist; the actual provisioning script is
  `scripts/ci/setup-ci-runner.sh`.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…visioned

PR #680's original goal was to make the e2e suite a required merge
gate. With the workflow now retargeted at the always-on Tokyo stack
(previous commit), keeping `e2e-gate` as `(required)` would block
every PR until the Tokyo IAM OIDC role + SSM parameter +
admin-org quota are provisioned — a chicken-and-egg.

Removing the gate job for now. The two-job structure (changes → e2e)
still works for `workflow_dispatch` trial runs and for PR CI feedback
(non-blocking). Re-add an `e2e-gate` job and the corresponding branch
protection rule once a first green run is observed.

Header comment updated to flag the deferred-required-check status so
future contributors know why the workflow exists without being gated.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

AWS IAM CreateRole rejects U+2014 (em-dash) in the --description
argument with a validation error. Replace the em-dash with an ASCII
hyphen so the script runs cleanly during bootstrap.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… gap

PR #680 is sourced from a fork (G4614/boxlite). GitHub Actions does
NOT pass repository variables (the `vars` context) to workflow runs
triggered by `pull_request` from external forks — security rule to
prevent fork PRs from reading upstream secrets/vars.

Result: even though `gh variable set AWS_E2E_CLOUD_REGION` and
`AWS_E2E_CLOUD_ROLE_ARN` succeeded on boxlite-ai/boxlite, the workflow
run on this PR's head saw both as empty strings, and
`aws-actions/configure-aws-credentials@v4` failed at input validation
with "Input required and not supplied: aws-region" before any OIDC
handshake could occur.

Fix: hardcode the values in the workflow's env: block. Both are
acceptable to commit:

- `ap-northeast-1`: region name, public infrastructure information.
- IAM role ARN: contains the AWS account ID (12 digits). AWS docs
  classify account IDs as "sensitive, not secret"; the role's safety
  is enforced by its trust policy (which restricts AssumeRole to
  GitHub OIDC tokens with sub matching `repo:boxlite-ai/boxlite:*`
  patterns), not by hiding the ARN. Industry-standard pattern in OSS
  CI infrastructure.

After this PR merges, future PRs sourced from same-repo branches WILL
see the repo vars again, but the hardcoded values remain the source
of truth.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

apps/api/Dockerfile uses `COPY apps/libs/sdk-typescript/`, `COPY apps/dashboard/`,
`COPY apps/package.json` and friends — paths that exist at the repo root,
not inside apps/api/. Using `apps/api` as the build context made
buildx report:

  ERROR: failed to compute cache key: failed to calculate checksum of
  ref ...: "/apps/libs/sdk-typescript": not found

Switch to `-f apps/api/Dockerfile .` so the context is the repo root.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…y branch

Previous trust policy enumerated 3 specific subject patterns:
  - repo:.../ref:refs/heads/main
  - repo:.../pull_request
  - repo:.../environment:e2e-cloud

workflow_dispatch on a feature branch (e.g. chore/e2e-required-merge-gate)
produces subject `repo:.../ref:refs/heads/chore/e2e-required-merge-gate`,
which matched none of the 3. STS rejected with
"Not authorized to perform sts:AssumeRoleWithWebIdentity".

Switch to `repo:boxlite-ai/boxlite:*` — accepts any subject from this
specific repo. Scope is still bounded to a single repo (no other repos
can assume this role), and the role's IAM policy is least-privilege
(only the boxlite-e2e-ci stack resources). Trade-off: feature branches
can trigger e2e-cloud via workflow_dispatch, which is a feature here
(needed for iterative debugging) rather than a risk.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…te.a from source)

Runner binary rebuild via Go CGO links libboxlite.a, but the prebuilt
libboxlite.a from latest release (v0.9.5) doesn't have the
boxlite_rest_options_set_path_prefix symbol that apps/runner Go code
references — main has drifted ahead of release.

Linker error:
  undefined reference to `boxlite_rest_options_set_path_prefix'

Two paths to fix:
  (a) Build libboxlite.a from Rust source in the workflow (+10-15min,
      requires cross-build chain for musl + libkrun)
  (b) Skip runner rebuild — Tokyo runner EC2 already runs a working
      binary ABI-compatible with the deployed API

Going with (b) for now. The current Tokyo runner has been up 21+ hours
and passes the API↔runner handshake checks we observed earlier. PR
changes touching apps/runner Go code are not exercised by this
workflow as a result; that's a follow-up that can wire `make
dist:runner` (which builds libboxlite.a from source) into the build path.

Removed steps:
  - actions/setup-go@v5
  - Install runner build deps (libx11/libxtst/libxinerama)
  - Determine version + download libboxlite.a
  - Rewrite apps/go.work
  - Download Go modules per module
  - Build daemon / computer-use / boxlite-runner
  - Upload runner binary to S3
  - SSM Deploy runner binary to EC2

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…M needs decorator metadata)

Source-mode container with tsx crashed immediately at module load:
  /boxlite/node_modules/typeorm/decorator/src/decorator/columns/PrimaryColumn.ts:72
  ColumnTypeUndefinedError: Column type for User#id is not defined
  and cannot be guessed. Make sure you have turned on an
  "emitDecoratorMetadata": true option in tsconfig.json.

Cause: tsx uses esbuild under the hood, which has long-standing
non-support for `emitDecoratorMetadata: true`. TypeORM's @column /
@entity / @PrimaryColumn decorators rely on `reflect-metadata` calls
the compiler EMITS when that flag is set; without them, TypeORM can't
infer column types and bails before the app even starts.

Switch to ts-node, which uses the TypeScript compiler properly and
honors emitDecoratorMetadata from the referenced tsconfig:

  ENTRYPOINT ["yarn", "ts-node",
              "--project", "apps/api/tsconfig.app.json",
              "--transpile-only",
              "-r", "tsconfig-paths/register",
              "apps/api/src/main.ts"]

- --project: point at apps/api/tsconfig.app.json (where
  emitDecoratorMetadata and experimentalDecorators live).
- --transpile-only: skip type-checking at startup (faster cold boot;
  the prod webpack build is the source-of-truth type gate, and it's
  already known to fail on main with 160 errors — see Dockerfile.source
  header).
- -r tsconfig-paths/register: resolve `@boxlite-ai/*` path aliases
  defined in tsconfig.base.json at module-load time.

Both ts-node (10.9.1) and tsconfig-paths are already in apps/package.json
dependencies (used by the typeorm migration scripts), so no dep change.

Cold start is now ~10-30s instead of tsx's ~5-15s — acceptable for the
ALB health-check window (3 retries × 30s + delays = ~90s minimum). If
it still races, will follow up by extending the health check grace
period at the ECS service or task-def level.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The IAM action `ecs:ExecuteCommand` is evaluated against BOTH the task
ARN AND the cluster ARN. Granting it on the task alone produced:

  AccessDeniedException: not authorized to perform: ecs:ExecuteCommand
  on resource: arn:aws:ecs:.../cluster/boxlite-e2e-ci-ClusterCluster-...

Add the cluster pattern to the Resource list so the "Init admin-org
sandbox quota" step can exec into the Api task.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The "Init admin-org sandbox quota" workflow step execs into the Api
container and runs `psql` against RDS to seed sandbox quota. The
source-mode Dockerfile didn't install postgresql-client, so the step
failed with `sh: 1: psql: not found`. Add it to the apt install line.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Schema drift: post-deploy migration 1781016743403 renamed
max_{cpu,memory,disk}_per_sandbox → max_{cpu,memory,disk}_per_box on
the organization table. The quota-init UPDATE failed with:
  ERROR: column "max_cpu_per_sandbox" of relation "organization"
  does not exist

Rename all three column refs in the workflow to match the live schema.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The previous run actually applied the quota UPDATE successfully:
  UPDATE 1
  ... | 4 | 8192 | 20

But psql wrapped the row across multiple lines and triggered a
"--More--" pager prompt over the ECS Exec session, so the
'4 *\| *8192 *\| *20' grep didn't match.

Add `-A -t -P pager=off` and `PAGER=cat` so the SELECT row is a
single unaligned line "<uuid>|4|8192|20", then grep on a tighter
'\|4\|8192\|20$' anchor.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The quota row printed exactly as expected:
  4a1eef70-8734-4814-b7a5-0ca3522a8760|4|8192|20

but `grep -E '\|4\|8192\|20$'` still failed because SSM Session Manager
uses CRLF line endings, so the `$` anchor sees `\r` immediately before
end-of-line, never the literal `20`.

Pipe through `tr -d '\r'` first so the anchor matches reliably.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

The bubblewrap-sys / libkrun-sys / e2fsprogs-sys crates have build.rs
scripts that vendor their C dependencies via git submodules. Without
the submodules initialized the build panics:

  bubblewrap vendor source not found at .../vendor/bubblewrap
  Initialize submodule: git submodule update --init --recursive

These C deps are runtime requirements of the runner binary (which
runs inside the EC2 host), NOT of the Python SDK client. The build.rs
files all honor BOXLITE_DEPS_STUB=1 and emit a no-op
`/nonexistent` linker hint — exactly the right behavior here.

Set the env var on the SDK build step so we don't need to also init
submodules or install meson/ninja on the GHA runner.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…broadened

…ass dead per-service role ARNs

The e2e-ci stack's per-service Task/Execution roles (ProxyTaskRole,
OtelCollectorTaskRole, SshGatewayTaskRole + their Execution pairs)
were deleted from IAM out-of-band — same drift as ApiTaskRole-
batkzzas before this PR's session recreated it. Live ECS TDs still
reference the dead ARNs, so new task launches fail at AssumeRole
NoSuchEntity.

Workaround: at deploy time, resolve Api's currently-live taskRoleArn +
executionRoleArn (those were recreated earlier with sst:app=boxlite
and trust ecs-tasks.amazonaws.com), and override the cloned TD's
roles to point at those. Both trust principals match any ECS service,
so Proxy / OtelCollector / SshGateway can each AssumeRole the Api
role. Least-privilege rough edge: borrowers get Api's S3 + log perms
they don't need — acceptable for e2e-ci (no prod traffic). Admin's
`sst deploy --stage e2e-ci` will recreate per-service roles
properly; we can drop this override then.

… to test their deploy paths

…w_call

Refactor the e2e-cloud workflow so the Api build+deploy chain is no
longer duplicated inline. Adds a deploy_api job that workflow_call's
.github/workflows/deploy-api.yml (mirroring how deploy_runner already
workflow_call's deploy-runner.yml). Both deploys are gated on actual
source changes via the existing `changes` paths-filter:
  - runner_chain → deploy_runner
  - api          → deploy_api
PRs touching only api skip the ~11 min runner build chain; PRs
touching only runner skip the Docker buildx + ECS register-TD +
wait-services-stable round-trip; PRs touching only tests skip both.

E2e job (pytest) now needs all three (changes + deploy_runner +
deploy_api) and reuses the same skip-if-failure-only gate
(!failure() && !cancelled() && any-relevant-change) so it still runs
when an upstream job was correctly skipped.

Dropped from the inline e2e job:
  - ECR login step + Build & push Api image step (deploy-api.yml)
  - Deploy Api (rolling) step incl. clone-TD + UpdateService + ALB
    healthy poll (deploy-api.yml does it + env patches for stale
    S3_ACCESS_KEY / storage-bucket name + role override).
  - SSM-agent-online preflight check on the runner (obsolete since
    deploy-runner switched to SSH+SCP via EC2 Instance Connect).
  - ECR repo describe preflight (now exercised inside deploy-api.yml).
Kept inline (still needed by pytest):
  - Resolve stack resources (cluster, ALB DNS/TG, runner id, S3 bucket).
  - /api/health probe through the LB before tests run.
  - Init admin-org sandbox quota via ECS Exec.
  - Python SDK build/install + pytest profile/snapshot setup + run.
  - On-failure CloudWatch + journalctl dump.

Net: -104 lines, one source of truth per deploy.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… PortSpec impl

merging upstream/main into the PR brought in #741's PortSpec-based
WithPort but the session's earlier stub (added to unblock the runner
build before #741 landed) remained in place, causing duplicate
declarations:
  ports redeclared in struct boxConfig
  WithPort redeclared in this block
  cannot use portMapping{} as PortSpec value in append

Remove the stub block: stub's ports field, portMapping struct, and
stub WithPort func. #741's PortSpec + WithPort + ports []PortSpec are
the canonical definitions.

…uota init

The previous step UPDATE'd organization WHERE id='4a1eef70-...' — a
UUID that happened to be the admin's default-org id in earlier e2e-ci
stack instances. After this PR's DB schema reset (required to recover
from #736's pre-launch migration squash being deployed against a stack
whose history was already past those migrations), the app re-runs
initializeAdminUser at boot and creates a new admin user + auto-
generates a new default-org UUID. The hardcoded id no longer matches,
UPDATE touches 0 rows, SELECT returns empty, the step fails.

Switch the SQL to resolve the admin's default org via a subquery
against organization_user (userId='boxlite-admin' AND
isDefaultForUser=true) — that membership row is what app code already
uses to find the admin's working org, and survives any future schema
reset where the org UUID changes.

Merging the substantive bits of #745 and #746 here so PR #724's
deploy-app-services CI can actually push an otel-collector image:

* otel-collector/builder-config.yaml: fix module paths after #730
  moved everything under apps/ (was: ../../../api-client-go etc.,
  now: ../../../apps/api-client-go). The OCB build was failing with
  `filepath does not exist: /boxlite/otel-collector/exporter`. (#745)
* otel-collector/Dockerfile: apk add python3 make g++ so node-gyp
  can compile any musl-incompatible native add-on during workspace
  `yarn install`. Kept even after dropping dockerode below — small
  safety net in case future deps reintroduce a native build. (#745)
* apps/package.json: drop unused dockerode + @types/dockerode. They
  were inherited from the Daytona import in #460 but never imported
  in source. Drops the dockerode -> docker-modem -> ssh2 ->
  cpu-features chain; cpu-features was the optional native addon
  that forced the toolchain workaround in the first place. (#746)
* apps/yarn.lock: regenerated (-161 lines).
* apps/api-client-go/api/openapi.yaml: regenerate to catch up with
  main's existing `assignedRoleIds.default: []` drift so the
  api-client-drift PR check passes.

… gone

The previous commit kept #745's apk add as a safety net, but cpu-features
was the only musl-incompatible native dep in the workspace and it came
in only via the now-removed dockerode chain. Verified locally: yarn
install on node:22-alpine completes without any compiler toolchain.

PR-on-open triggering serializes every PR against the shared Tokyo
stack (see concurrency: e2e-cloud-shared, cancel-in-progress: false).
The suite is slow enough that gating every PR open / push on it just
queues runs behind each other for hours. Push-to-main keeps the
post-merge regression signal; workflow_dispatch covers ad-hoc PR
validation when wanted.

Today an OtelCollector deploy on chore/e2e-required-merge-gate failed
with "ECS rolled back. PRIMARY=...:7 expected ...:6" — two parallel
Deploy App Services runs (push + dispatch on the same SHA) both
registered task definitions, and one's UpdateService rolled the other
back.

Add per-workflow concurrency groups against the shared Tokyo stack
to prevent the race. cancel-in-progress: false because a half-applied
ECS rolling update / EC2 userdata swap is worse than waiting.

- deploy-api.yml: group=deploy-api-shared
- deploy-app-services.yml: group=deploy-app-services-shared
- deploy-runner.yml: group=deploy-runner-shared
- _deploy-single-service.yml: group=deploy-single-service-<service_name>
  (parameterized so different services parallelize but same-service
  callers serialize — belt-and-suspenders against the outer group)

Resolve stack resources was picking the API LB target group via
TargetGroups[0] without checking how many target groups were attached.
Blue/green deploys or extra listener rules can attach more than one TG
to an ALB; in that case the e2e suite would silently bind smoke traffic
to the wrong TG. Use the same assert_one guard as the cluster and LB
checks above. Hoist the LB ARN into a variable so the count + the
final lookup share one resolution.

…002)

CodeRabbit / Trivy DS-0002 flagged the source-mode container running as
root. Switch to the pre-existing `node` user (UID 1000 in node:24-slim)
right before HEALTHCHECK + ENTRYPOINT. All RUN/COPY happen as root above,
so the installed tree is read-only at runtime — least-privilege without
needing a chown -R.

Previously the e2e-cloud.yml pipeline glued deploy_{runner,api,app_services}
and the pytest suite into one workflow_dispatch entry, so the only
way to "rerun the tests" was to also redeploy everything (workflow_dispatch
forces all three deploy gates true). With the Tokyo stack as a shared
singleton that gets left in whatever state the last run produced, this
made cheap "rerun against current stack" cycles much more expensive
than they need to be.

* New: .github/workflows/e2e-cloud-test.yml. workflow_call + workflow_dispatch.
  Contains only the e2e job — resolve resources, probe LB, init
  admin-org quota, build SDK, configure pytest, run suite, collect
  logs on failure. Shares the e2e-cloud-shared concurrency group so a
  standalone test dispatch and an in-flight deploy queue against each
  other (can't race the Tokyo stack).
* e2e-cloud.yml: e2e job is now a thin `uses:` wrapper around the new
  workflow. Gating logic (skip-if-upstream-failed, paths-changed-only-
  on-push) is preserved at the wrapper level; standalone dispatch on
  e2e-cloud-test.yml skips those gates and just runs.

Header on e2e-cloud-test.yml warns explicitly that the stack state is
the dispatcher's responsibility — results reflect whatever's deployed,
not the branch the workflow was dispatched from.

The single `runner_source` filter triggered the full ~10 min libboxlite
Rust build on any path in the runner's dep graph, including Go-only
diffs (apps/runner, apps/daemon, sdks/go, ...) that just relink against
the existing libboxlite.a without changing it. Split into two filters:

* libboxlite_chain: paths whose content ends up in libboxlite.a
  (src/boxlite, src/shared, src/deps, sdks/c, scripts/build, Cargo.{toml,lock})
* go_runner_chain: Go paths that consume libboxlite.a but don't
  contribute to its bytes (apps/{runner,daemon,common-go,api-client-go,
  libs/computer-use}, sdks/go)

`build_c_sdk` now runs only when libboxlite_chain changed.
`build_runner` switches libboxlite_source to "release" (pull
v${VERSION} tarball from GitHub Release) when libboxlite_chain didn't
change, "build" (use sibling build_c_sdk artifact) otherwise.
`build_runner`'s `if:` adds the !failure() && !cancelled() guard so
the skipped build_c_sdk on Go-only diffs doesn't cascade-skip it.

Also drop the dead `src/api-client/**` path from both deploy-runner.yml
and e2e-cloud.yml — that directory doesn't exist in the repo, so the
entry never matched anything.

workflow_dispatch / workflow_call behavior is unchanged — both still
force libboxlite_changed=true and rebuild from source. Only push-event
auto-triggering is optimized.

…layers

The bare ${SQL} interpolation went through GHA bash → aws ecs --command
→ sh -c → psql -c — four layers of double-quote parsing. The SQL's own
PG identifier quotes ("organizationId", "organization_user", etc.)
collided with the inner `\"...\"` bounds and got stripped, so psql
received the bare token `organizationId` which Postgres case-folds to
`organizationid` and reports as missing.

Encode the SQL to base64 on the runner (base64 chars never need quoting),
inline that into the --command string, then `base64 -d | psql -f -`
inside the container. psql sees the literal SQL bytes unchanged.

Last dispatched e2e-cloud run failed exactly here; the column is in
the schema (migrations/1741087887225-migration.ts:64), the bug was
purely shell-escape.

Drop this block before merging to main. GH won't expose
workflow_dispatch on a brand-new workflow until it has run at
least once; the push trigger (scoped to this branch and to
self-modifications only) gives us that first run.

POST /api/snapshots and GET /api/snapshots?name=... no longer exist
on the API — there is no snapshot controller in apps/api/src/**.
PR #735 (feat(box): create boxes from curated images) replaced the
pre-register-then-boot model with lazy curated-image pulls at box
start, so the e2e test workflow no longer needs to seed snapshot rows.

The pre-registration block was failing the "Configure pytest profile
p1" step with `Cannot POST /api/snapshots` 404. The previous run got
masked by the SQL-escape bug in quota init (now fixed); this surfaced
as the next blocker.