docs(project): correct stg e2e receipt with artifact-delivery root cause

[rschlaefli]

Summary

Corrects the stg e2e receipt in the v1.2.0 integration plan. An earlier note recorded the e2e as blocked with no reachable signing key and no sandbox capacity; both were wrong. This records the corrected live evidence.

What changed

• Core execute now proven passing in stg. A JWT minted from the Infisical key CODEAPI_JWT_PRIVATE_JWK_JSON (OKP/Ed25519, kid codeapi-stg-2026-06-29) derives exactly the deployed JWKS verifier key. print(123) through the deployed codeapi-api returns HTTP 200, code 0, ~48ms. No infra change was needed.
• Cold start proven. The KEDA wake path scaled codeapi-sandbox-pool-waker and codeapi-sandbox-runner from zero and brought up a sandboxspot KVM node; the runner became ready in ~3-4 minutes. Earlier 502 ECONNREFUSED responses were just the cold runner.
• Artifact delivery is a pre-existing stg storage defect, not this revision. The single all-in-one seaweedfs pod runs one volume server at Max=8 volumes. Volumes 1-7 serve the default collection and volume 8 serves trypost-media, leaving the codeapi-files collection with zero writable volumes. The master logs No writable volumes and no free volumes left for collection codeapi-files, and each S3 PutObject returns 500, which the file-server retries ten times then fails. PRD is unaffected because its codeapi-files collection owns volume 8.

Validation

• Live POST /v1/exec in stg at 929ec4d: HTTP 200, stdout 123, code 0.
• Live artifact write in stg at 929ec4d: HTTP 200, code 0, artifact_delivery failed; root cause traced to the SeaweedFS volume layout above.
• PRD file-server shows zero retryable-500 lines, confirming the defect is stg-specific.

Notes

• Docs-only change; no code paths affected.
• The SeaweedFS codeapi-files volume allocation is a separate, out-of-scope remediation.