Proactive update notification via post-run async check

Problem

Users currently have no way to know that a new version of swamp is available unless they manually run swamp update --check. This means users can run outdated versions for weeks or months without realizing an update exists.

Proposed Solution

Implement a post-run async update check with cached results (the approach used by Deno itself):

1. After a command completes, fire off a lightweight HEAD request to the stable artifact URL (artifacts.systeminit.com/swamp/stable/...) in the background
2. Write the result (latest version + timestamp) to a local cache file (e.g., ~/.swamp/last-update-check.json)
3. On the next invocation, if the cache indicates an update is available, print a one-line banner after command output:

A new version of swamp is available: 20260225.143022 → 20260226.091500
Run `swamp update` to install.

Key design points

• Zero latency impact — the check happens after the command finishes, never blocks execution
• Rate-limited — only check once every 24 hours (based on cached timestamp)
• Suppressible — respect a SWAMP_NO_UPDATE_CHECK=1 environment variable for CI/scripting contexts
• Offline-safe — if the network request fails, silently skip (no errors shown to user)
• Dev build aware — skip the check for dev builds (where SHA is empty), since developers running from source don't need update prompts

Additionally: version staleness warning (zero-network fallback)

Since the version string encodes the build date (CalVer), we can also warn users if their installed version is more than 30 days old, with no network call required:

Your swamp version is 45 days old. Run `swamp update --check` to check for updates.

This provides coverage even when offline or when the update check is disabled.

Alternatives Considered

• Startup check — checking before command execution adds latency risk; rejected
• Blocking check on every run — poor UX, slows down every command; rejected
• GitHub release RSS/webhook — useful for teams but doesn't help individual CLI users; could be complementary

Summary of Implementation

This feature adds a background update notification system. Changes would be needed in:

• Domain layer (src/domain/update/): Add an UpdateNotifier service that manages the cache file and determines whether to show a notification
• CLI layer (src/cli/): Hook into the post-command lifecycle to trigger the async check and display cached notifications
• Infrastructure layer (src/infrastructure/update/): Reuse the existing HttpUpdateChecker HEAD request logic for the lightweight version check
• Cache file: Store last-check timestamp and latest available version in ~/.swamp/last-update-check.json

The existing UpdateService.check() and HttpUpdateChecker already handle the core logic of resolving the stable URL redirect to extract the latest version — the new code would wrap this in an async, cached, non-blocking layer.