build: route Python installs through CFS

[Fabio Cavalcante (fabiocav)]

Summary

• route every repository-owned Python install job through the azfunc/public/upstream-public CFS feed
• authenticate before UsePythonVersion with a single authoritative index (onlyAddExtraIndex: false)
• remove the legacy public/internal Python feed parameter from the shared test template and its callers

Surface audit

The repository owns one Python package and four install-capable Azure DevOps job templates:

• eng/templates/jobs/build.yml
• eng/templates/jobs/ci-tests.yml
• eng/templates/official/jobs/build-artifacts.yml
• eng/templates/official/release/build-artifacts.yml

No repository-owned npm, NuGet/.NET, uv, Docker, detached helper, or customer sample/template install path applies. No pip configuration is committed.

Validation

• Parsed all changed YAML and structurally verified each install-capable template has exactly one PipAuthenticate@1, targeting public/upstream-public with onlyAddExtraIndex: false, before UsePythonVersion@0.
• Built the wheel and sdist through CFS from an isolated Python 3.13 environment and empty pip cache in a path containing spaces.
• Ran pip-audit .: no known vulnerabilities found.
• Proved binary-wheel availability with a separate empty cache per case:
  • Windows build graph: CPython 3.10, 3.11, 3.12, 3.13, and 3.14 (31 wheels each)
  • Windows test graph: CPython 3.13 and 3.14 (76 wheels each)
  • Linux release graph: CPython 3.11 and 3.13 (31 wheels each)
• One initially uncached Windows CPython 3.12 wheel returned the expected anonymous CFS ingestion 401. An enrolled identity ingested it without an exception; a final anonymous cold-cache replay of all nine cases then passed.
• Verbose request evidence contained 190 HTTPS connections, all to pkgs.dev.azure.com or Azure Artifacts *.vsblob.vsassets.io storage; no request reached PyPI or pythonhosted.org.
• Audited wheel/sdist contents and the workspace artifact surface: no feed config files, credentials, lockfiles, or node_modules were included.

Baseline blocker

The CFS pipeline migration itself is healthy: all five build jobs, dependency installation, authentication, and SDL checks passed. Python 3.13/3.14 tests resolve the newly released mcp==2.0.0 and fail 11 MCP tests because MCP 2 moved SDK types from mcp.types to mcp_types._types.

This is confirmed as an unchanged baseline issue:

• this PR SHA changes only the six pipeline YAML files; pyproject.toml, azure/, and tests/ are byte-identical to dev
• a detached archive of exact upstream dev@baf7256701db19bbce9e90f657614a555c0e4c39, installed from a new CFS-only cache, independently resolved mcp==2.0.0 and reproduced exactly 11 failed, 875 passed, 2 skipped, with all failures in tests/decorators/test_mcp.py
• the Azure Python 3.13 and 3.14 job logs show the same MCP version and identical 11-test failure set

No MCP pin, downgrade, or unrelated SDK adaptation is included in this CFS PR.