[Feature Request] 2-networking: add a tfvars-driven IAM map on the shared-VPC host project (parity with Stage 3's kms_keys iam)

## Feature Description
Stage 3's KMS keys accept an `iam` map directly in tfvars — granting a new principal a role on a specific key is a pure data change. Stage 2's shared-VPC host project has no equivalent: the `iam` block in `branch-net-envs.tf` (lines 57–63) is hardcoded to resolve members from three fixed `service_accounts` keys (`gke-dev`, `project-factory-dev`, `project-factory-prod`), all bound to `roles/dns.admin`. A delegated-grants pattern exists directly below but is commented out (lines 64+). Add a tfvars-driven additional-IAM map to `env-spoke-projects`.

## Use Case
Onboarding any workload whose deploy identity needs a scoped grant on the host project — e.g., a blueprint that creates a firewall rule in the shared-VPC host project under an impersonated, least-privilege deploy identity — currently requires editing `branch-net-envs.tf`. `modules/project`'s `factories_config` doesn't cover IAM bindings (only custom roles, observability, org policies, quotas), so there is no file-drop alternative either. The Stage 3 KMS pattern proves the tfvars-driven shape already works in this repo.

## Proposed Solution
Add a tfvars-driven `iam_bindings_additive`-style map on `env-spoke-projects` (or finish and expose the existing commented-out delegated-grant pattern), mirroring Stage 3's `kms_keys..iam`.

## Compliance & Deployment Context
* **Target Deployment Type(s):**
* [ ] US Region Restricted (e.g., Access Policy constraint)
* [ ] FedRAMP Medium
* [x] FedRAMP High
* [x] DoD IL5
* [x] DoD IL4
* [ ] All / General
* **Relevant NIST 800-53r5 Controls:** AC-6 (least privilege) — enables scoped host-project grants for workload deploy identities instead of broadly-privileged ones.

## Reusability Check
Stellar Engine prioritizes reusability.
* [x] I have checked if this functionality can be achieved by extending an existing module or blueprint. (`modules/project` factories don't cover IAM; the commented-out delegated-grant block is unfinished.)
* [x] I have verified that this does not duplicate existing functionality.

## Alternatives Considered
Editing `branch-net-envs.tf` per grant (current state — a stage source edit for a routine operational need); granting broader roles to avoid repeat edits (worse for least privilege).

## Additional Context
Verified at `main` @ `3728fc98`. This is the concrete reason a least-privilege deployment-identity design can be done with a tfvars-only change on the Stage 3/KMS side but not on the Stage 2 side. Regime applicability (verified): the identical hardcoded `roles/dns.admin` block exists in both networking variants (`2-networking-a-fedramp-high/branch-net-envs.tf:57-63` and `2-networking-b-il5-ngfw/branch-net-envs.tf:58-62`, same commented-out delegated-grants pattern), so FedRAMP High, IL4, and IL5 deployments are all affected.

Start by comparing 2-networking-a-fedramp-high/branch-net-envs.tf lines 57–63 with 2-networking-b-il5-ngfw/branch-net-envs.tf lines 58–62, then inspect the Stage 3 KMS tfvars IAM shape and the commented delegated-grants blocks. Done means env-spoke-projects accepts additional IAM data for the shared-VPC host project in both networking variants without editing branch-net-envs.tf per grant.

Written by the indexing model from the issue text.