Fix the update hint going silent and checking the wrong source

[woksin]

Summary

The "update available" hint could stay silent for a day after a release, and never matched how a Homebrew install actually updates.

Fixed

• The update hint no longer stays silent for up to 24 hours after a release. An "up to date" answer is now re-checked within the hour, so a check that ran moments before a release no longer hides every release after it.
• Homebrew and other native installs are now checked against the GitHub releases they actually update from, rather than the NuGet package they never install.
• cratis update now always asks the source rather than trusting a cached answer.
• The update hint no longer goes missing after commands that take more than five seconds, such as workbench, run, and screenplay generate.

[woksin]

Reviewer context.

How it went wrong, pinned from the reporter's cache and the release metadata (2026-07-30 UTC):

Time	Event
18:25:52	GitHub release v2.3.5 created
18:26:20	update check ran, recorded "latest = 2.3.4", cached for 24h
18:26:45	NuGet published 2.3.5
18:27:08	Homebrew tap updated to 2.3.5

The check landed in the 53-second window between the release and the package becoming visible. With a single 24-hour interval that answer was then served until the next day, hiding both 2.3.5 and 2.3.6.

Two defects, two commits:

1. The check always asked NuGet, though only a dotnet tool installs from there. DetectStrategy() already knew the install was Homebrew and GetInstalledVersion already knew how to ask brew — only the version lookup was unaware. Cache keys are now separated per source so an answer from one is never served for the other.
2. The 24-hour interval applied to both answers. "Update available" stays true until the user installs it and is still held a day; "up to date" is held an hour, and an answer that has fallen behind the installed version is not trusted at all.

Plus cratis update now bypasses the cache, and the update check no longer carries a deadline measured from process start.

Verification

• dotnet clean + dotnet build -c Release — 0 warnings, 0 errors; dotnet test — 565 passed
• The two freshness specs were confirmed to fail against the previous 24-hour behavior, so they pin the regression rather than restate the fix
• Exercised live from published binaries: a native build reads the GitHub release and caches under github:Cratis/cli; a dotnet-tool build reads NuGet and caches under Cratis.Cli; a seeded 2-hour-old "up to date" entry now re-checks and shows the hint, where the old code stayed silent

Note on rate limits — the GitHub releases endpoint is unauthenticated (60 req/hour/IP). The caching keeps a single user well inside that, and a rate-limited response is treated like any other failed check: no hint, nothing blocked.

Possibly the same root cause as #34 ("Update doesn't run update - it thinks it has the latest", closed). That report is a Mac user being told they were current while other surfaces showed a newer version, which is what the wrong-source defect produces. Worth a look before assuming it stayed fixed.