fix: update stale nested bundle URIs when reloaded from different source

[colombod]

Summary

Fixes the persistent-state half of microsoft-amplifier/amplifier-support#62.

When a parent bundle (e.g., foundation) is overridden to a local path via settings.local.yaml, nested bundles previously persisted with git+ URIs kept their stale URIs indefinitely. This PR ensures registry entries are refreshed when a bundle is reloaded from a different source.

Root Cause

BundleRegistry._load_single() has an update block (lines 506–510) that refreshes version, loaded_at, and local_path for known bundles — but it did not update uri. Combined with persisted state loaded from registry.json on init, this meant:

1. First session (no overrides): nested bundles get git+ URIs → persisted to registry.json
2. Second session (with local overrides): _load_single() reloads the nested bundle from a file:// URI, but the existing entry's uri field is never updated
3. registry.json retains the stale git+ URI across all subsequent sessions

Change

+5 lines in amplifier_foundation/registry.py — surgical addition to the existing update block:

if update_name:
    state = self._registry[update_name]
    if state.uri != uri:                          # ← NEW
        logger.debug(                             # ← NEW
            f"Updating URI for '{update_name}': {state.uri} → {uri}"
        )                                         # ← NEW
        state.uri = uri                           # ← NEW
    state.version = bundle.version
    state.loaded_at = datetime.now()
    state.local_path = str(local_path)

The URI is only updated when it actually differs, with a debug log for traceability. For same-URI reloads this is a no-op.

Evidence

Diff stats

• amplifier_foundation/registry.py: +5 lines (production fix)
• tests/test_registry.py: +164 lines (3 regression tests)

Test results

Suite	Before	After	Delta
amplifier-foundation full suite	298 passed ✅	301 passed ✅	+3 new, 0 regressions

New regression tests (TestNestedBundleURIUpdate)

Test	What it verifies
test_persisted_nested_bundle_uri_updates_on_reload	Pre-populated git+ URI in registry.json gets updated to file:// when the same bundle is loaded from a local path
test_persisted_uri_update_survives_save_reload	Updated URI persists correctly across save() → new BundleRegistry cycle
test_same_uri_reload_does_not_change_entry	Reloading from the same URI is a no-op (guards against unnecessary mutations)

Companion PR

This is the first of two PRs for issue #62. The companion PR in amplifier-app-cli changes get_bundle_categories() to read from the in-memory registry instead of stale registry.json on disk. This foundation PR should merge first (it fixes the persistent state that the CLI reads).

How to verify end-to-end

After both PRs merge:

1. Add bundle.added.foundation: ../../amplifier-foundation to settings.local.yaml
2. Run any Amplifier session (to trigger bundle loading with the override)
3. Run amplifier bundle list --all
4. Confirm nested bundles show file:// paths, not git+ GitHub URLs

[sadlilas]

Review: Approve

Independently verified the root cause by tracing all read sites for state.uri in the registry. This is not a display bug -- stale URIs cause functional issues in bundle resolution, include resolution, and update checking.

The fix correctly adds state.uri = uri to the existing update block in _load_single(). This is consistent with the established pattern -- version, loaded_at, and local_path are already updated there. The URI was the only field missing from the update set.

Verified that update_name is always set for persisted bundles. No scenario where a persisted nested bundle would skip this update.

Tests are solid: URI update on reload, persistence across save/load cycles, same-URI idempotency.

Non-blocking note: amplifier reset --remove cache does not delete registry.json (separate category in reset.py). After cache reset, stale URIs persist until the next bundle load triggers this fix. Worth a follow-up issue.

LGTM. We recommend merging this PR and not merging the companion app-cli PR #92 -- once this fix lands, the first session corrects all persisted URIs and the display self-heals permanently.