Preserve staging configuration in ECS task definitions

[suguanYang]

Summary

• preserve active staging API database-pool, provider URL, storage-path, extension, and broker settings in the ECS template
• preserve active staging worker database/Redis pool, PDF processing, model, provider, and parser-column settings
• add a renderer contract for the non-secret staging configuration snapshot verified from EKS on 2026-08-13

This keeps the Fargate migration behavior aligned with the current EKS staging workloads while retaining intentional ECS differences: IAM task-role S3 credentials, public service URLs, and ENVIRONMENT=staging.

Part of Ontos-AI/knowhere-api-infra#21, Ontos-AI/knowhere-api-infra#22, and Ontos-AI/knowhere-api-infra#19.

Verification

• uv run pytest deploy/ecs/test_render_task_definitions.py -q (6 passed)
• uv run pytest apps/api/tests apps/worker/tests/contract -q (388 passed)
• make lint
• make typecheck
• uv lock --check
• git diff --check
• read-only comparison against knowhere-staging using kubectl --context aws-knowhere-prod

No AWS, Kubernetes, database, queue, or deployment changes were made.

Deployment Notes

Changed non-secret staging environment values include S3_TEMP_PATH, API/worker pool sizes, provider URLs, SUPPORTED_EXTENSIONS, worker PDF controls, model selections, and parser-column compatibility. No migration or queue-routing change is included. Merge to main only; do not promote to staging until ECS prerequisites exist because a staging push automatically attempts migration and ECS deployment.

Checklist

• Tests were added or updated when behavior changed
• Public docs, examples, or OpenAPI contracts were updated when needed
• Database migrations are idempotent and safe to deploy (not applicable; no migration)
• Logs, errors, and validation paths avoid leaking secrets or user data
• The pull request description explains any breaking or user-visible change