docs: require Build gate in the §9 required-checks note

docs/Architecture.md

@@ -117,7 +117,7 @@ When changing the preload contract, follow this loop:
 
 ## 9. Known gaps / follow-ups
 
-- **Required status checks not configured.** The "Protect Main" ruleset requires a PR (with review-thread resolution), Copilot review, and code quality — but **no required *status* checks**. So the Build Module / Dependency Review / Upstream-Compatibility signals do not block `gh pr merge --auto` (Dependabot auto-approve): a dependency PR can merge before they pass. Configure the **Build Module** (`Build and test module (…)`), **Upstream-Compatibility** (`Validate upstream compatibility tooling` — the only PR job running the conflict-surface drift gate; omitting it lets a Dependabot PR auto-merge against a stale upstream fingerprint), and **Dependency Review** checks as required status checks to close this (the `Dependabot-Auto-Approve.yml` header already assumes it). Note: those workflows are path-filtered, so requiring them blocks PRs that don't trigger them (e.g. docs-only) — pair the requirement with an always-running status shim, or scope it appropriately.
+- **Required status checks.** The "Protect Main" ruleset enforces a PR (with review-thread resolution), Copilot review, and code quality, but historically had **no required *status* checks** — so `gh pr merge --auto` (Dependabot auto-approve) could complete before the build/drift/security checks passed. The gate workflows now **always report**: they trigger on every PR and a `changes`/`pr-changes` job skips the expensive work (skip == passing check) when no relevant paths changed, so they can be required without blocking docs-/CI-only PRs. Required set to configure on the ruleset: **`Build gate`** (the always-present aggregate for the matrix build — *not* the per-OS `Build and test module (…)` legs, which aren't created when the matrix job is skipped), **`Validate upstream compatibility tooling`** (the only PR job running the conflict-surface drift gate; omitting it lets a Dependabot PR auto-merge against a stale upstream fingerprint), and **`dependency-review`**. (The `Dependabot-Auto-Approve.yml` header already notes that `--auto` relies on the Dependency Review and build/test checks being configured as required status checks.)
 - **`Az.Resources` is not in `monitoredModules`.** It is the observed #193 collision source, but its copy and future drift are **not** inventoried. Among monitored modules the `Microsoft.Extensions.*` transitives are observed only in `MicrosoftTeams` (a single shipper → not in the conflict surface), recorded as `trackingScope` on the blocked entries. Note #193 was a *bundle-vs-consumer* collision (DLLPickle's preloaded copy vs Az.Resources'), which the cross-module drift gate does not model — the regression guard is the integration test that keeps these transitives out of `bin`, not the matrix. Re-adjudicate manually if an Az.Resources change is suspected, or add it to `monitoredModules` to track it directly.
 - **EXO/Teams ALC ownership** is not yet captured — a bare `Import-Module` doesn't eager-load their identity assemblies; the probe needs a representative `-ProbeCommand`.
 - **Multi-TFM (net9.0/net10.0):** deferred; the methodology is TFM-parameterizable. net9.0/net10.0 are ALC-capable, so the `block` verdicts in §3 carry over to them. The `net8.0` bundle is confirmed to load on **PS 7.6 / .NET 10 via roll-forward** (Az.Resources import verified, no #193 regression) — a positive signal that multi-TFM is mostly a packaging exercise, not a behavioral one, on ALC-capable runtimes.