Refine native-driver pipeline architecture

### Feature Summary

Address the actionable, non-blocking engineering-system feedback deferred from #4991 after the initial Cosmos native-driver pipeline is operational.

### Feature Description

PR #4991 intentionally delivered a first-cut pipeline while deferring broader integration improvements. Follow up on Daniel Jurek’s review suggestions:

- Make the shared EngSys job matrix the clear source of build configurations: operating system, hardware architecture, target identifier, agent pool, and target-specific configuration.
- Remove duplicated matrix concepts between pipeline job generation and per-target build scripts. Build scripts should derive compiler details from the selected target where appropriate.
- Move stable Linux apt dependencies into build-configuration metadata rather than branching over target IDs in the job template.
- Remove build-irrelevant `risk` metadata from the executable matrix and track support risks in documentation or planning artifacts instead.
- Confirm and document the final supported target matrix, including the policy for Intel macOS.
- Evaluate whether the local end-to-end supply-chain rehearsal remains necessary for the developer workflow; keep it only if its distinct purpose is documented and tested.
- Revisit whether reusable job and step templates should live under `eng/pipelines/templates` and whether a standard Rust CI archetype can replace pipeline-local wiring.
- Keep new cSpell entries sorted according to repository conventions.

The manual `/azp run` model is not part of this follow-up: PR #4991 already resolved the blocker by keeping the main Cosmos pipeline off PR triggers because public PR builds cannot access the required internal resources.

### Use Case

Reduce pipeline-specific machinery and align the native-driver build with the Rust repository’s established EngSys patterns, making future target additions easier to review and maintain.

### Alternatives

Keep the first-cut pipeline unchanged. This remains functional but preserves duplicated configuration and increases maintenance cost as the target matrix grows.

### Additional Context

Follow-up to #4991 and related to #4967. Source review threads include Daniel’s matrix architecture, apt dependency, support-matrix, local rehearsal, template-location, and CI archetype suggestions.

Start by comparing the shared EngSys job matrix, pipeline job generation, per-target build scripts, and eng/pipelines/templates with PR #4991 and its review feedback. Define the supported target matrix and document the decisions around dependencies, risk metadata, templates, local rehearsal, and Intel macOS; done means duplicated configuration is removed and the final policy is documented and validated.

Written by the indexing model from the issue text.