Track workload-aware rollout procedure for measured compose and image updates

## Context

Terraform can add or remove replicas for the service mesh demo. The remaining gap is the rollout procedure for measured compose or image changes.

This matters because compose hashes are admission evidence. During a measured update, operators need a clear path that keeps the cluster healthy while old and new workload revisions are admitted in the right order.

## Scope

Define and implement a workload-aware rollout procedure for measured compose or image updates.

The procedure should cover:

- workload-group rollout order,
- health checks between rollout steps,
- drain or leader-transfer behavior for stateful services such as Postgres,
- admission policy handling while old and new compose hashes coexist,
- rollback behavior when a new revision fails health or admission checks,
- operator commands and expected success signals.

## Non-goals

- Do not change the deterministic compose image rule. Image identity should stay in compose source.
- Do not treat this as a generic Terraform provider issue. Slot-based replica operations are tested. The gap is the repo's workload-aware rollout workflow.
- Do not require Kubernetes.

## Acceptance Criteria

- A documented rollout procedure exists for the HA Postgres demo.
- The procedure supports measured compose or image changes without manual Consul token injection.
- The procedure defines how admission policy allows both old and new compose hashes during the rollout window.
- The procedure defines health gates for Consul, Envoy, webdemo, and Patroni/Postgres.
- A failed rollout has an explicit rollback path.
- README Current Limits can link to the procedure or remove this limit.