Screen an agent's environment request against the catalog

Developers wait days for environments, so an agent now requests them through a provisioning pipeline. The agent can touch the cloud account, so the pipeline screens every request against a catalog of approved settings, even when the agent was tricked into asking for more.

Write screen_provision_request(request_fields, team_active_envs): the check every request passes through.

• request_fields (list of str): the request, as key=value fields such as "size=medium".
• team_active_envs (int): how many environments the requesting team already runs.
• Return "approve", "deny:<key>" (a line the agent may never cross), "escalate:<key>" (outside the defaults, so a platform engineer decides), or "deny:malformed".

The catalog keys, in catalog order, are size, region, ttl_hours (the environment's lifetime), budget_usd and network. Values are compared exactly, with no trimming or case changes. Check in this order and return at the first problem:

1. Go through the fields in input order. Split each at its first =. A field with no =: "deny:malformed". A key that is not a catalog key: "deny:<key>". A key already seen in this request: "deny:<key>".
2. The first catalog key, in catalog order, that the request does not include: "escalate:<key>".
3. size other than small, medium or large: "escalate:size".
4. region other than us-east or eu-west: "escalate:region".
5. ttl_hours: if it is not 1 to 9 digits (0 to 9 only), or it is 0: "deny:ttl_hours". Over 72: "escalate:ttl_hours".
6. budget_usd: if it is not 1 to 9 digits (0 to 9 only), or it is 0: "deny:budget_usd". Over 500: "escalate:budget_usd".
7. network of prod or production: "deny:network". Any other value except dev or staging: "escalate:network".
8. team_active_envs of 5 or more: "escalate:team_active_envs".
9. Otherwise: "approve".

Then, in a sentence or two: why deny an unknown key instead of ignoring it?