fix: create scoped staging S3 secret from activation creds

[EDsCODE]

Summary

• create a server-managed HTTPS S3 secret scoped to the managed warehouse staging prefix
• build it from the explicit credentials already supplied in the tenant activation payload
• refresh it alongside the primary DuckLake S3 secret when STS credentials rotate
• preserve the secret during shared-worker session cleanup

Why

The primary DuckLake secret may use the cache proxy's HTTP transport. Delta staging reads need a more-specific direct HTTPS secret. Creating that secret through DuckDB's credential chain fails on multi-tenant workers because their per-tenant credentials are brokered into the activation payload rather than exposed through a provider that DuckDB can discover.

Duckgres already has the correct temporary credential bundle, so it can create both secrets without another credential lookup.

Compatibility

The additional secret is only created for AWS S3 configurations with explicit credentials. Credential-chain deployments and custom S3-compatible endpoints keep their existing behavior.

Testing

• just ci

[github-actions]

Test Impact Plan

Deterministic summary of how this PR changes tests, CI runners, and coverage-risk signals.

Summary

Area	Added	Changed	Deleted
Test files	0	3	0
E2E/journey files	0	0	0
Workflow files	0	0	0

Signals

• Test cases: +2 / -0
• Assertions: +21 / -3
• Skips or known failures added: 2
• Workflow continue-on-error added: 0
• Workflow path filters added: 0
• Test commands removed from justfile: 0
• E2E/journey retry lines added: 0

Coverage risk: likely reduced

Warnings

• New skips or known failures (likely reduced)
  • 2 skip/allowlist line(s) added