deployments: support Git repository resources

[yanpgwang]

Problem

Deployments could template File and Memory resources but rejected Git repositories, so scheduled coding-agent work could not start from repository source even though direct Sessions already had a durable repository snapshot lifecycle.

Solution

• accept Mango-owned git_repository resources on Deployment create/update
• retain only URL, optional branch/commit checkout, and optional mount path in the Deployment
• resolve branch/default checkouts independently for every Run and reuse the existing Session snapshot/materialization pipeline
• keep each admitted Session frozen to its exact resolved_commit; Deployment responses intentionally expose no resolved commit
• validate anonymous HTTPS URLs, checkout values, and overlapping repository mounts at Deployment admission
• classify only deterministic repository/checkout absence as session_resource_not_found_error; transient transport failures remain unknown_error and do not pause schedules
• keep Deployment Run classification separate from the ordinary Session HTTP error envelope
• process scheduled claims in bounded concurrent batches and renew token-fenced leases during long Session admission
• update OpenAPI, API/capability docs, and provenance against the current CMA scheduled-Deployment design

Acceptance criteria

• Deployment repository templates round-trip through HTTP and PostgreSQL
• each Run creates its own immutable Session repository snapshot
• two Runs can resolve the same branch to different commits without changing the first Session
• both snapshots restore offline through the existing adapter-neutral materializer
• temporary clone failures do not auto-pause schedules, while deterministic missing resources do
• manual Run failures never change Deployment pause state
• slow repository admission renews its schedule claim without blocking unrelated due Deployments
• stale claim owners cannot renew after a replacement claim

Non-goals

No private repository credentials, vendor authorization fields or headers, submodule/LFS expansion, repository Skill discovery, runtime Git attach/detach, push/PR credentials, or self-hosted Environment Worker mounting.

Durability, security, and migration

Repository work stays outside SQL transactions and uses the existing bounded, public-egress-only snapshot plus S3-compatible object lifecycle. Migration 00037_deployment_claim_tokens.sql adds an internal nullable claim token used to fence renewal ownership; rollback drops only that token column and returns to the earlier timestamp-only lease behavior. Deployment resource bodies remain JSON-backed and require no resource-data migration. Mango remains generic (git_repository) rather than adopting CMA's GitHub-specific authentication contract.

Verification

• make verify
• make docs-check
• make test-service
• targeted Deployment two-Run snapshot/materialization integration test
• race-tested claim concurrency, renewal, stale-owner fencing, error classification, pause behavior, and HTTP envelope tests