Make extension registry updates resilient to coordinated multi-extension version bumps

[JeffreyCA]

Fixes #8924

This PR makes extension registry updates resilient when several interdependent extensions are released at the same time.

The problem

When we recently bumped all the azure.ai.* extension versions together (#8896) and kicked off the per-extension release pipelines in parallel, every pipeline failed at the "Refresh Fig/Usage snapshots" step.

The root cause is that this step installs every extension from the in-repo registry.json through the full, dependency-resolving install path, and fails on the first error. But each pipeline rewrites only its own registry entry against the current tip of main, so the registry under test was transiently inconsistent. That produced failures such as:

• dependency azure.ai.inspector required by azure.ai.agents was not found
• installed dependency azure.ai.connections version 1.0.0-beta.1 does not satisfy constraint "~0.1.0-preview"

We ended up reconciling the registry by hand. This PR closes the two gaps behind that outcome.

Change 1: decouple snapshot generation from dependency resolution

What this means: the ADO extension release pipeline should no longer fail on "Update_Registry - Refresh Fig/Usage snapshots", when the registry is momentarily inconsistent during multi-extension version bumps.

Command snapshots only need each extension's own binary so its commands register. They do not need the registry's dependency graph to be internally consistent.

• Adds a --no-dependencies flag to azd extension install that installs only the named extension, without resolving or installing its declared dependencies and without enforcing the installed-dependency version constraints.
• The Fig/Usage snapshot helper now uses it, so each extension installs independently of whatever versions its siblings happen to be at.
• The flag is honored on both the fresh-install and the reinstall/upgrade paths, so it behaves consistently whether or not the extension is already installed.
• It is opt-in: a normal azd extension install <id> still installs the full dependency graph exactly as before.
• Nothing is dropped from the snapshot, because every extension that ships a binary is also a top-level registry entry installed on its own, and the artifact-less microsoft.foundry meta-package contributes no commands.

Change 2: cross-dependency registry validation

What this means: a genuinely broken registry (a dependency pinned to a version that was never published) is blocked at PR time (not during release pipeline) with a clear, actionable message, instead of slipping through and breaking installs for users. Warnings and mid-rollout publishing are not blocked, so routine releases are unaffected.

Registry validation previously checked per-extension fields but never verified that a declared dependency could actually be resolved, so an inconsistent registry only surfaced as a cryptic install failure inside a snapshot test.

• The validator now checks every declared dependency against the versions the registry actually publishes, reusing the same version-constraint matcher the installer uses so validation mirrors install-time resolution.
• An unsatisfiable constraint is an error (it can never be resolved); an entirely absent dependency id is a warning (it may be provided by another registered source).
• A new TestRegistryFileIsValid test runs in the ext-registry-ci workflow, which triggers on any pull request that changes registry.json, so the automated per-extension registry-update PRs are gated on it.
• It fails only on errors, never warnings, and its output names the exact extension, constraint, and available versions, turning a genuine inconsistency into an early, readable failure on the PR instead of a silent one that ships.

Updating microsoft.foundry before all dependencies are updated:

Passing registry consistency but failing snapshot tests:

Successful run:

Behavior at a glance

Scenario	Before	After
"Refresh Fig/Usage snapshots" step during a coordinated multi-extension bump	Fails on the first extension whose dependency graph is transiently inconsistent, blocking the registry update	Each extension installs independently via --no-dependencies; the step no longer depends on registry-wide consistency
azd extension install <id> (no flag), end user	Installs the extension and its declared dependencies	Unchanged
azd extension install <id> --no-dependencies	Flag did not exist	Installs only the named extension; dependencies are neither resolved, installed, nor constraint-checked, on both fresh install and reinstall/upgrade
Registry with a dependency constraint no published version can satisfy	Surfaces later as a cryptic install failure inside a snapshot test	Reported as a validation error on any PR that changes registry.json, naming the extension, constraint, and available versions
Registry with a dependency id absent from the registry	Not detected by validation	Reported as a validation warning (the dependency may be provided by another source)
azd x publish while a single extension is mid-rollout	Publishes the entry	Unchanged: publishing does not run registry validation, so legitimately transient states are not blocked

Testing

• Added unit coverage for skipping dependencies on both fresh install and upgrade, and for bypassing the installed-dependency constraint check.
• Added validator coverage for the satisfied, unsatisfiable-as-error, absent-as-warning, and empty-constraint cases, plus the production-registry gate.
• Regenerated the Fig and Usage command snapshots to include the new flag.
• The existing extension suite, gofmt, and golangci-lint all pass.

[JeffreyCA]

Updating microsoft.foundry before all dependencies are updated:

Passing registry consistency but failing snapshot tests: