feat(lifecycle): run non-tunnel upgrades under the provided r_* credential

[I-am-nothing]

What

Closes the documented UpgradeHandler KNOWN GAP (referenced from api-platform's module_lifecycle.go upgradeRequest doc comment): a deployed (non-tunnel) upgrade now runs its (from, to] migrations under the provided per-(app, module) r_* credential with search_path = the provided app schema — exactly like Install already does.

Pairs with the api-platform deployed-lifecycle-transport PR: the api side already sends {from, to, appId, schema, credential:{username, token}} on the non-tunnel path (field names mirror installRequest verbatim, by design, so this adoption needs no wire change).

How

• UpgradeRequest = VersionRequest + InstallRequest — the api-side upgradeRequest shape, verbatim.
• Extracted injectLifecycleContext out of injectInstallContext; install, upgrade, and downgrade now share the single context-folding implementation, so credential/schema semantics cannot drift between the lifecycle verbs. Same rules as install: env-URL supplies host/port/database, body supplies username/token, "credential": {} falls through to the dev pool.
• Module.Tx (the ScopeApp runner) already resolves the pool from db.CredentialFrom(ctx) and SET LOCALs search_path from db.SchemaFrom(ctx) — no runner changes needed.
• Back-compat: a bare {from, to} body (the dev-tunnel path) behaves byte-for-byte as before — no schema/credential injected, env-pool fallback.
• Downgrade shares the decoder and gets the identical treatment (a deployed downgrade had the identical gap).

Lambda-envelope reachability (checked, no change needed)

The lifecycle routes are mounted on m.router (mountSystemRoutes), and both the real Lambda transport (lambda.Start(runtime.NewLambdaHandler(m.router))) and the dev /__mirrorstack/lambda-invoke shim wrap that same router. X-MS-Internal-Secret is exempt from the envelope's identity-header strip (msAuthSecretHeaders), so internalAuth on /__mirrorstack/platform/* validates it normally. Lifecycle install/upgrade are therefore servable through the envelope as-is.

Platform-side note (out of scope here)

EnsureModuleRole (api-platform) does not set ALTER ROLE ... IN DATABASE ... SET search_path. That is harmless for this path (the SDK explicitly SET LOCALs the schema inside every migration transaction) and for runtime invokes that carry AppSchema in the envelope — but any invoke arriving without AppSchema leaves the r_* role on the cluster-default "$user", public search_path, which is what the hand-built E2E had to patch with a manual ALTER ROLE. Recommend the api-platform transport PR either always populate AppSchema or add the ALTER ROLE default as defense-in-depth.

Tests

• Upgrade with credential+schema → runner receives ctx with credential (env-base host/port/db + body username/token) and correct schema.
• Bare {from, to} → no schema, no credential (dev path pinned unchanged).
• Malformed credential/schema (wrong JSON types) → clean 400, no panic.
• "credential": {} → falls through like install.
• Downgrade credential parity pinned.

go build ./..., go vet ./..., go test ./... green.

🤖 Generated with Claude Code