Support per-team dedicated OSS buckets

Problem
Currently, the system uses globally configured OSS buckets via environment variables TEMPLATE_BUCKET_NAME and BUILD_CACHE_BUCKET_NAME defined in packages/shared/pkg/storage/storage.go.All teams and API keys share the same buckets. Isolation is only based on build_id prefixes, not bucket-level isolation.There is no database relation between teams/API keys and buckets, making multi-tenancy, quota, permission, and lifecycle management impossible.

Proposed Solution
Orchestrator / Template Manager
Add bucket configuration fields to the teams table to support dedicated OSS buckets per team.
Modify bucket resolution logic in storage.go to use team-specific buckets first, fall back to global defaults.
Inject team bucket info into context during auth; all template/sandbox/build operations use the correct bucket dynamically.
Make Orchestrator / Template Manager support runtime bucket switching with backward compatibility.

Recommendation
Use per-team bucket isolation instead of per-API-key for simplicity and multi-tenancy.
Keep global default buckets for backward compatibility.
Support template/build buckets first, then extend to sandbox data buckets.
Enable independent quota, permissions, lifecycle, compliance, and cost tracking per team.

Environment
Storage config: packages/shared/pkg/storage/storage.go
Global env vars: TEMPLATE_BUCKET_NAME, BUILD_CACHE_BUCKET_NAME
Affected components: Orchestrator / Template Manager / API Server
Current isolation: build_id prefix only, no bucket-level isolation

Start with packages/shared/pkg/storage/storage.go and trace how TEMPLATE_BUCKET_NAME and BUILD_CACHE_BUCKET_NAME are resolved, then inspect the teams table and authentication context in the Orchestrator, Template Manager, and API Server. Done means team bucket fields are supported, team-specific buckets take precedence with global fallback, and template/build operations switch buckets at runtime while preserving backward compatibility.