feat(cli): show update notice when a newer Data Designer version is available

[eric-tramel]

Priority Level

Medium (Nice to have)

Is your feature request related to a problem? Please describe.

After users can run data-designer --version, the CLI should be able to help them notice when their installed Data Designer version is behind the latest published release. Today there is no CLI or log call-to-action that tells users a newer version is available or how to upgrade.

This matters for support and security-sensitive situations: users may be running an old version with fixed bugs, changed defaults, or yanked dependency constraints without realizing it.

Depends on

• feat(cli): add data-designer --version #597

Describe the solution you'd like

Extend data-designer --version so that the first line remains the installed version string, then append an update notice only when a newer stable version is available.

Desired base behavior from #597:

0.6.0

Desired behavior when a newer version is available:

0.6.0
╭─ 🚀 Update available ─────────────────────────────╮
│ New Data Designer version available: 0.6.1        │
│ Upgrade with: uv tool upgrade data-designer       │
╰───────────────────────────────────────────────────╯

If the CLI can detect that Data Designer is installed as a project dependency rather than a uv tool, the command should instead point at the project workflow:

0.6.0
╭─ 🚀 Update available ─────────────────────────────╮
│ New Data Designer version available: 0.6.1        │
│ Upgrade with: uv add --upgrade data-designer      │
╰───────────────────────────────────────────────────╯

Implementation expectations:

• Keep line 1 as the installed version string so simple scripts can still parse the current version.
• Use Rich styling consistent with the existing terminal UI (rich, panels, existing console/theme helpers, and concise emoji usage).
• Include the literal phrase New Data Designer version available in the notice.
• Use a short timeout and fail closed: if the latest version cannot be checked, print only the local version and do not slow down the command materially.
• Avoid showing prereleases unless the installed version is itself a prerelease or a flag/config explicitly opts into prerelease checks.
• Cache the result briefly, likely under the existing Data Designer home/config directory, to avoid a network request on every invocation.
• Provide an opt-out for environments that do not want outbound network checks, for example an environment variable such as DATA_DESIGNER_DISABLE_VERSION_CHECK=1.
• Add tests covering newer version, current version, network/check failure, opt-out, prerelease handling, and command selection.

Describe alternatives you've considered

• Showing the update notice on every CLI invocation. This is more proactive, but it risks adding network latency and noise to normal workflows.
• Logging the update notice during DataDesigner() initialization. This would reach Python API users, but it could surprise notebook/batch workflows and should probably be considered separately after the explicit CLI flow exists.
• Relying only on package manager output. That does not help users who are debugging through the Data Designer CLI.

Agent Investigation

Current findings from the codebase and open issues:

• There is no existing Data Designer update-availability check in CLI startup, logging setup, or interface initialization.
• CLI startup currently only bootstraps default model settings before invoking Typer: packages/data-designer/src/data_designer/cli/main.py and packages/data-designer/src/data_designer/cli/runtime.py.
• Existing UI helpers already use Rich and emoji-based messages in packages/data-designer/src/data_designer/cli/ui.py.
• Existing version metadata lookup exists for agent introspection via importlib.metadata.version("data-designer").
• Docs have an outdated-version CTA for docs pages, but that is separate from installed package version notification: docs/overrides/main.html.
• I did not find an open issue specifically requesting a new version available CLI/logging CTA.

Additional context

The exact package source can be PyPI or another release source, but it should be chosen deliberately. PyPI is the likely default for data-designer users installed via pip, uv tool, or uv add.

The output should stay useful in both human and automation contexts: local version first, optional human-friendly Rich notice after that.

Checklist

• I've reviewed existing issues and the documentation
• This is a design proposal, not a "please build this" request

[zeel2104]

Open for contributon?