fix(tui/update): ignore cached upstream upgrade metadata (#376)

[zemaj]

Summary

• treat cached version.json files written by the upstream openai/codex release checker as stale so the TUI stops advertising 0.50.0
• write the current release repo (just-every/code) into the cache so future reads can distinguish our fork from upstream data
• cover the legacy/current cache handling with small unit tests

Testing

• cargo test -p code-tui read_version_info
• ./build-fast.sh

Fixes #376.

[zemaj]

Summary:

• Reject legacy openai/codex cache entries and persist release_repo: just-every/code so stale metadata no longer triggers repeated update prompts.
• Added serialization + load tests to prove stale caches are ignored, fresh caches load, and release_repo is written back out.

Tests:

• cargo test -p code-tui read_version_info_rejects_legacy_repo_cache -- --nocapture
• cargo test -p code-tui read_version_info_accepts_current_repo_cache -- --nocapture
• cargo test -p code-tui serialized_version_info_includes_release_repo -- --nocapture
• ./build-fast.sh

Risks:

• End-to-end fetch path still depends on live GitHub; consider adding integration coverage or retries if API quota issues surface.

[zemaj]

Summary:

• Add TTL-aware caching with clock-skew tolerance, dedupe concurrent update checks via a global async mutex, and switch to atomic temp-file writes so version.json never corrupts and stale legacy caches are ignored.
• Extend updates.rs with async tests that cover stale refetches, fresh-cache short-circuiting, concurrent dedup, malformed JSON recovery, and path/permission edge cases.
• Confirm background callers still succeed and documented the new behavior/regressions in reports/pr_385_review.md.

Validation:

• cargo test -p code-tui --lib updates::
• ./build-fast.sh

Risks / Follow-ups:

• Refresh still depends on live GitHub responses; consider introducing retries or a mockable client for hermetic testing.
• UI snapshot coverage for update toast dedupe is still pending; future PR may add VT100 assertions.