[57514396] Use central TSA config for Foundation source analysis

[v-goradojcic]

Ports the already-merged main implementation from #6738 to release/2.0-experimental (Bug 57514396). Companion to the release/2.0-stable port in #6762.

What this does

• Foundation source analysis (the injected sdl_sources job) now consumes the centrally maintained tsaoptions.foundation.json from WindowsAppSDKConfig/main (via a data-only WindowsAppSDKTsaConfig alias pinned to refs/heads/main, replicated with checkout_all_repos plus a condition: false discovery job), instead of the committed root .config/tsaoptions.json.
• Pinning the TSA data-only alias to WindowsAppSDKConfig/main (even on this servicing branch) is intentional and consistent with how WindowsAppSDKConfig is already consumed here, so a future TSA Area Path change is a single edit in central Config rather than a per-servicing-branch update.

Scope / deliberate non-changes

• TSAUpload behavior is unchanged (globalSdl.tsa.enabled untouched; no perStage.sdl_sources.tsa.enabled introduced).
• Build-job TSA / area-path materialization is unchanged.
• Root .config/tsaoptions.json is intentionally retained for now.
• Servicing-specific pipeline behavior on this branch is untouched.

One file changed (build/WindowsAppSDK-Foundation-Official.yml), 26 insertions, no deletions — semantically identical to the merged main change (#6738) and the release/2.0-stable port (#6762).

This branch is actively built by the Foundation Official pipeline, so after merge the normal Official flow on release/2.0-experimental can provide runtime validation of the central-config redirect.

Reference: Azure DevOps Bug 57514396 (tracking item — intentionally not auto-closed by this PR).

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.