[Documentation] il5/postgresql classic firewall rule sits outside Stage 2's hierarchical firewall policy governance — document the coexistence or migrate

## Description of Documentation Need
Stage 2 governs environment firewalling via a **hierarchical** firewall policy associated to the Networking **folder** (`module.firewall-policy-default`, `2-networking-a-fedramp-high/main.tf:44-52`, called with `parent_id = module.folder.id` and no `region`, dispatching to `modules/net-firewall-policy/hierarchical.tf`). The PostgreSQL blueprint instead creates a classic, network-scoped `google_compute_firewall` resource (`main.tf:36`) directly in `network_project_id`. Both are valid GCP constructs and coexist without conflict (hierarchical policies evaluate before classic VPC rules), but the blueprint's rule is invisible to anyone auditing the environment through its firewall policy (`gcloud compute firewall-policies rules list` does not show it) — it lives in a separate enforcement layer from the one Stage 2 establishes, and nothing in either README explains the split.

## Target Audience
Security auditors reviewing the environment's firewall posture; operators reasoning about why a blueprint rule doesn't appear in the folder policy.

## Proposed Location
A note in `blueprints/il5/postgresql/README.md` and/or the Stage 2 README.

## Content Outline / Draft
1. State that FRH/IL5 blueprints (currently) use classic per-network rules as a simpler, blueprint-local mechanism.
2. Explain the coexistence and evaluation order (hierarchical → global/regional network policies → classic VPC rules).
3. Note where to look when auditing (`firewall-policies rules list` vs. `firewall-rules list`).
4. Alternative to documenting: migrate the blueprint to emit a `google_compute_firewall_policy_rule` against Stage 2's existing hierarchical policy — happy to discuss which direction maintainers prefer.

## Compliance Context (if applicable)
Auditability/governance-transparency gap rather than a control failure; relevant to firewall-review procedures under FRH/IL4/IL5 (e.g., CM-6/SC-7 evidence gathering). Verified at `3728fc98`: both networking variants govern via the same hierarchical `firewall-policy-default` module (`2-networking-a-fedramp-high/main.tf:44` and `2-networking-b-il5-ngfw/main.tf:43`), so the split applies regardless of regime; the postgresql blueprint ships in both the FRH and IL5 trees.

Start with blueprints/il5/postgresql/README.md, the Stage 2 README, and the referenced Terraform locations: 2-networking-a-fedramp-high/main.tf:44-52, 2-networking-b-il5-ngfw/main.tf:43, and main.tf:36. Verify the audit commands for policy and classic firewall rules, then document their coexistence, evaluation order, and separate audit locations; completion means both relevant audiences can understand the split without inspecting code.

Written by the indexing model from the issue text.