Registered relative file extension sources break after changing directories

[m7md7sien]

• Make sure you've installed the latest version using instructions

Output from azd version
Originally reproduced with azd 1.33.0 (29133b640536436db9b56f8db4b1781cb136e5ba) on Windows amd64. Also reproduced with an actual rebuilt public core at c0ed8a2ab2e173d8c5bf5983c6780fe9e98b8cec; the registration/file-source loader code is identical to public main 56ea57424b65c72ec4202313de16b5bdac4747e1.

Describe the bug
azd extension source add --type file --location ".\registry with spaces.json" validates and saves the source successfully, but persists the relative location verbatim in global user configuration. A later install using that registered source name from another working directory fails with ERROR: no extensions found. The source file still exists in the original directory.

The documented source-add contract is global configuration, not a project-relative source. This was found by internal testing, not a customer report.

To Reproduce

1. Use one isolated AZD_CONFIG_DIR and two sibling working directories A and B.
2. Put a valid local extension registry in A as registry with spaces.json.
3. In A, run azd extension source add --name local-test --type file --location ".\registry with spaces.json" --no-prompt.
4. Verify the saved extension.sources.local-test.location remains the literal relative path.
5. In B, run azd extension install <extension-id> --version <exact-version> --source local-test --no-dependencies --no-prompt.
6. Observe exit 1 and ERROR: no extensions found.
7. Run the identical install from A: it succeeds and installs the exact requested artifact.

Expected behavior
Persist the validated file source's absolute location when registering it, so a named global source continues to work from other directories. Preserve existing resolution order (working directory, then user configuration directory), absolute file locations, URL sources and bundle behavior. Do not guess the original directory or silently migrate legacy relative entries when read later; those can be removed and re-added from the original directory or with an absolute location.

Environment
Information on your environment:
* Language name and version: Go 1.26 for the rebuilt public core
* IDE and version: N/A; Windows amd64 command-line reproduction

Additional context
Current-source verification used 13 actual CLI commands with an isolated configuration, local fixture artifacts and a loopback-only URL registry. Absolute file, URL and config-directory-relative fallback controls installed the exact same SHA-256 from B. All fixture installations were uninstalled afterward; no shared configuration, credentials, Azure services or paid operations were used.

This is host source-registration behavior, not an evaluation/dataset extension runtime regression. It is separate from explicit version-pin enforcement and selected $ref parsing.