Fix misleading slug display in stardag modal CLI (v0.7.3)

[andhus]

Summary

stardag modal deploy and stardag modal stardag-api-key create printed the workspace/environment slug by reading the active CLI profile's TOML (prof["environment"]). When env vars or a custom config_provider default-factory override the resolved IDs, the slug pulled from the active profile may not correspond to the resolved UUID — producing hypothetical output like:

Environment: <env-a-uuid> (env-b-slug)

…where the UUID resolves to environment A but the slug is read from a profile pointing at environment B. Deployed bytes were always correct; only the printed line was misleading.

Fix

• Added get_cached_workspace_slug / get_cached_environment_slug reverse lookups in stardag/config/cache.py (UUID → slug, against ~/.stardag/id-cache.json).
• Replaced _get_profile_slugs with _resolve_display_slugs in stardag/_cli/modal.py. The slug shown is now always the one that actually maps to the resolved UUID, or omitted when there is no cache entry — instead of guessing from the active profile.

Includes minimal CHANGELOG.md + RELEASE_NOTES.md entries for v0.7.3.

Test plan

• pre-commit run passes (ruff, pyright, prettier)
• Reverse lookup verified against a populated id-cache (UUID resolves to its actual slug, not the active profile's slug)
• Local smoke: stardag modal deploy ... from a project that overrides STARDAG_WORKSPACE_ID / STARDAG_ENVIRONMENT_ID via a custom config_provider default factory now prints the slug matching the override, not the active profile's slug

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes misleading slug output in the stardag modal CLI by deriving the displayed workspace/environment slugs from the resolved UUIDs (via the local id-cache) rather than from the active CLI profile TOML, and documents the change for release v0.7.3.

Changes:

• Added UUID → slug reverse-lookup helpers to stardag/config/cache.py using ~/.stardag/id-cache.json.
• Updated stardag/_cli/modal.py to use reverse-lookups for display (_resolve_display_slugs) instead of reading profile TOML slugs.
• Added v0.7.3 entries to CHANGELOG.md and RELEASE_NOTES.md.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
RELEASE_NOTES.md	Documents the CLI display fix for v0.7.3.
lib/stardag/src/stardag/config/cache.py	Adds cached reverse lookups (UUID → slug) for workspace/environment.
lib/stardag/src/stardag/_cli/modal.py	Switches slug display logic to use id-cache reverse lookup.
CHANGELOG.md	Adds a v0.7.3 changelog entry describing the CLI display fix.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[andhus]

Thanks for the review — both comments addressed in df7d933.

1. Registry-name mismatch (real bug, fixed)

You're right that the original _resolve_display_slugs had a residual inconsistency: both deploy(--profile foo) and stardag_api_key_create(--stardag-profile foo) resolve IDs under a temporarily-overridden STARDAG_PROFILE, then restore the env (and clear the config cache) before the display call. So get_config().context.registry_name would point at the active profile rather than foo — and on a multi-registry setup the id-cache reverse lookup would either miss or hit the wrong registry's slugs.

Fixed by pinning the registry to the URL the IDs were actually resolved against:

• New _registry_name_for_url(api_url) helper that reverse-looks up the registry name from list_registries() (the TOML [registry.<name>] table).
• _resolve_display_slugs now takes api_url and derives registry_name from it. Callers pass env_vars["STARDAG_API_URL"] (deploy) or api_url from _resolve_stardag_context (api-key create) — both of which were captured while the override was active.
• Falls back to (None, None) (no slug shown) when the URL has no matching TOML registry, instead of silently using the wrong one.

2. Double id-cache load (minor, fixed)

Collapsed get_cached_workspace_slug + get_cached_environment_slug into a single get_cached_slugs(registry, ws_id, env_id) -> tuple[str | None, str | None] so the cache file is loaded once per invocation.

Verified

Reverse lookup against a populated id-cache returns the slug that actually maps to the resolved UUID. Unknown UUIDs and URLs that don't match any configured TOML registry both fall back to no slug, instead of silently displaying a wrong one.

🤖 Generated with Claude Code