[skip ci] Prepare first-push runners and preserve supervisor execution - #255

The native release archive currently strips the executable bit from helper-lambdas/stacktape-supervisor, causing container tasks to fail with permission denied. Preserve the bit, verify extracted native artifacts, and exercise a real extraction/execution in the archive test.

Update the Console pointer for background preparation of empty Git deployment runners at setup, and disclose the earlier storage billing in CLI setup and the GitOps guide. The generated CLI documentation comes from that guide. Default stopped disks cost $8.80/month in eu-west-1, plus brief setup compute; repository, dependency and build caches remain empty until the first push.

Validation: archive tests, native installation characterization, source-built runtime in live Lambda and container Git pushes, generated-file checks and the integrated repository gate. The paired Console PR contains the phase measurements, five-sample AWS timing results and cleanup verification.

Depends on https://github.com/stacktape/console-app/pull/104. Hosted dev rollout remains blocked by the owner-managed Paddle sandbox verification key; no placeholder or bypass was used.

Final qualification: 7 cold first pushes and 7 paired hibernation resumes per app, 42 successful pushes. Every sample passed business and unchanged-revision checks. Each cold round used a distinct host and new cache disk, prepared at Git setup with no repository/dependency/build cache. Each resume reused that round’s host. Workloads were confined to stacktape-e2e (597581086285), eu-west-1.

These conservative durations use AWS clock responses before the Git push and after readiness, rather than the drifting WSL clock. All seven observations are retained, including the first container push’s image-deploy fallback. Five rounds additionally recorded AWS dates on each target’s first correct response:

• lambda-5: first push 54 (50–63) s; resume 50 (47–61) s. Observer scheduling explains occasional gaps between these service timestamps and the conservative observations.
• lambda-25: first push 60 (51–61) s; resume 59 (51–65) s. Observer scheduling explains occasional gaps between these service timestamps and the conservative observations.
• container-node: first push 44 (40–48) s; resume 40 (39–42) s. Observer scheduling explains occasional gaps between these service timestamps and the conservative observations.

Before/after AWS phase breakdown (seconds; baseline is one fresh cold push per Lambda app on the current source-built runtime, after is the median of five rounds with service-response timing):

Current-source baseline readiness was 128 s / 138 s (n=1 each), rather than a new reproduction of the historical 87 s median. The image already uses AL2023 Minimal. Fresh EC2 launch → SSM Online took roughly 31–40 s. Starting at the webhook still leaves boot inside push timing; FSR adds recurring per-AZ fees and leaves guest/SSM startup. Setup-time hibernation moves boot and installed-tool reads outside the push, retains no customer build cache and needs no always-running compute. Preparation itself takes minutes and incurs brief compute charges. An immediate push before preparation completes keeps the ordinary startup path. The duplicate CLI install remains separate work.

Cleanup verified: original dev AMI pointer restored; owned CloudFormation stacks, projects/configurations, runners, root/cache disks, IAM roles/profiles and credential parameters absent; all three test AMIs/snapshots removed; builders terminated and their temporary security groups/keypairs absent; benchmark branches deleted; task reservation released. Both Git working trees are clean. No production action or credential change.

Raw phase rows, AWS timing observations and recovery/deletion evidence remain in the ignored .stacktape/cold-runner-20261021 directory.

🤖 Generated with Claude Code