restricted_paths: use typed source check results

Summary:
## This stack
This stack completes the second half of the restricted_paths AclManifest migration after the shadow comparison logging stack. The end result is that restricted_paths no longer relies on legacy construction flags or source-specific call paths: AclManifestMode owns source selection, config and AclManifest fetches are planned explicitly, the fetch results are shared between logging, enforcement, and metadata, and the public callers adapt to the final manifest-aware shape at the API boundary.

Visual flow: https://pxl.cl/9GjpF

Before this stack:
- Behavior was split across the old use_acl_manifest construction state, config-shaped metadata APIs, conditional_enforcement_acls, duplicated source fetches, and unimplemented AclManifest enforcement modes.
- Logging and enforcement could ask for overlapping source data independently, and Mononoke API/HG, SCS, and SLAPI still had to bridge around the incomplete manifest restriction shape.

After this stack:
- Construction and source planning are mode-driven. Disabled, Shadow, Both, and Authoritative modes choose the sources they need;
- Config and AclManifest fetches can be killed switched independently by rollout knobs;
- Shared typed fetch handles feed both comparison logging and enforcement;
- Conditional enforcement uses `enforcement_condition_sets`
- `AclManifestMode::Both` mode denies if either source denies;
- Authoritative-source errors are surfaced when the authoritative source cannot answer;
- Metadata lookup unions config and AclManifest results in Both mode.

This makes the codebase better because
- Source (config vs acl_manifest) choice is centralized,
- Fetch work is not duplicated
- Rollout controls are easier to reason about
- Restriction check results are typed instead of copied into loosely shaped structs, and API-specific adaptation happens at the edge instead of leaking through the restricted_paths internals.
- **The stack also stays reviewable by putting no-op setup and tests before behavior changes**

Remaining follow-ups after this stack are
- Schematized Scuba source/error parity
- The Eden API vector response shape tracked by TODO(T248658346)
- Reviewing the both-sources-disabled fail-open behavior also tracked by TODO(T248658346)
- Deleting rollout-only fallback paths after AclManifest enforcement is proven.

## This diff (no-op)
Removes the flat `SourceRestrictionCheckResult` adapter and has source fetch/check helpers return the typed path or manifest restriction check results directly. Shadow logging derives its source-specific and aggregate fields from those typed results through a small internal trait, preserving the current config-authoritative logging/enforcement behavior while avoiding a poorly typed struct that copied fields out of the real result types.

Reviewed By: lmvasquezg

Differential Revision: D103689094

fbshipit-source-id: d940b26b5bb256103daeb9e49c4af7230bc40213

Author: gustavoavena