Two interacting bugs in Sandbox.create({ envs }) that produced very
confusing behavior for users.

Bug #1 — snapshot fork dropped user envs.
createFromCheckpointCore re-bound only { Timeout int } from the request
body and forwarded originalCfg.Envs from cp.SandboxConfig, so calling
Sandbox.create({ snapshot, envs: { FOO: "x" } }) produced an empty $FOO
inside the guest. Fix: thread user envs through to the core via a
narrow userEnvs map[string]string parameter and merge them over
originalCfg.Envs (user keys win) after re-resolving the inherited
secret store. Scope is intentionally limited to envs — every other
field still inherits from the checkpoint.

Bug #2 — every env was sealed unconditionally.
secretsproxy.CreateSealedEnvs tokenized every entry of cfg.Envs, so
even user-supplied plaintext envs reached the guest as osb_sealed_…
tokens. echo $TEST_VAR returned the token, breaking every non-HTTP
use of the variable. Sealing is only meaningful for values sourced
from a SecretStore (so the MITM proxy can swap them on outbound
HTTPS). Fix: track which env names came from the store via a new
SealedEnvKeys []string on types.SandboxConfig (json:"-", never
persisted), populate it from resolveSecretStoreInto on both the
fresh-create and fork paths, plumb it through CreateSandboxRequest
(new field sealed_env_keys = 15) and the worker gRPC server, and
have CreateSealedEnvs only tokenize keys in that set. Non-sealed
envs pass through as plaintext; the proxy session is only registered
when there is something to substitute. On the fork path the seal-set
is computed before merging user envs so user keys are never sealed.

Worker deploy

The Azure dev box silently shipped without an OPENSANDBOX_S3_*
checkpoint store, which made every snapshot/fork RPC fail with
"checkpoint store not configured on this worker" — there was no
clear pointer at the missing config. Wire the worker to Azure Blob
via the existing OPENSANDBOX_S3_* env vars (the worker switches to
azureBlobClient when the endpoint contains .blob.core.windows.net,
see internal/storage/blob.go:39). Secrets are sourced from a
gitignored deploy/azure/.dev-env-secrets-<location> file and the
deploy now fails fast with a clear error if the checkpoint store
config isn't present.

Test coverage

New sdks/typescript/examples/test-snapshot-envs.ts asserts:
  - plain Sandbox.create({ envs }) → guest sees plaintext
  - Sandbox.create({ snapshot, envs }) → user envs survive the fork
    AND remain plaintext
  - Sandbox.create({ secretStore, envs }) → user envs are plaintext
    while store-derived envs are still sealed (osb_sealed_…)

Registered in run-all-tests.ts so it runs in the production suite.

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

Replace the SealedEnvKeys side-channel introduced in the previous
commit with a real provenance-preserving field. Three bug-classes
collapse into "structurally impossible" instead of "fixed by careful
threading".

Why
---

The previous fix added a parallel []string of env-var names that the
API layer computed, the proto carried, and the worker re-hydrated into
a set, all to tell the secrets proxy "tokenize these keys, not those".
That worked but kept the underlying mistake intact: secret-store-derived
plaintext was still inlined into cfg.Envs alongside user envs, and the
provenance had to be reconstructed from a side-channel everywhere
downstream wanted it. As soon as that channel desynced from the
values themselves (as it did on the snapshot/fork path) you got
either silent drops or silent plaintext leaks.

What
----

New types.SandboxConfig.SecretEnvs map[string]string (json:"-").
resolveSecretStoreInto now writes decrypted values into SecretEnvs
and never touches Envs. The two maps remain disjoint end-to-end:
through cfgForPersistence (only SecretAllowedHosts needs scrubbing
now — SecretEnvs can never reach PG since it's json-tagged out),
through the gRPC proto (CreateSandboxRequest.sealed_env_keys = 15
becomes secret_envs = 15, a real map), through the worker, and into
secretsproxy.CreateSealedEnvs which now takes (plaintextEnvs, secretEnvs)
directly. Everything in secretEnvs is tokenized; everything in
plaintextEnvs is forwarded as-is; user-supplied keys win on collision.

createFromCheckpointCore no longer needs the "compute seal-set BEFORE
merging user envs" ordering trick, because the maps are independent —
the merge order is irrelevant.

The "secretStore + snapshot/image" combination is now rejected at
the API edge with a clear 400. The pre-existing inherit-only contract
("a fork inherits the snapshot's secret store and cannot override it")
was previously enforced implicitly by "the fork pipeline doesn't bind
SecretStore from the body", which silently dropped a user-provided
store on fork. The first fix in this PR turned that silent drop into
a silent leak (parent-resolved store-B plaintext smuggled through
cfg.Envs into the fork-time merge under names that weren't in the
seal-set). With the rejection in place users get an explicit error
instead, and even if they could bypass it the leak is structurally
impossible because secret values no longer travel via cfg.Envs.

Test coverage
-------------

test-snapshot-envs.ts grew a 4th case asserting the rejection. All
10 assertions pass on the redeployed dev box. test-secretstore.ts
(the existing 21-assertion lifecycle suite) also passes unchanged
against the refactored worker, confirming the user-facing SecretStore
behavior is preserved.

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