fix(doctor): warn when the bundled agent skill is from an older bsk

[drakeo338]

Fixes #266.

The report is that bsk doctor prints ok agent skill up to date while the
installed SKILL.md is actually stale. Reading sync_installed_skills, the
check isn't lying about what it measured — up_to_date means the on-disk
SKILL.md matched the copy bundled in the running binary. It's just that
"up to date" is a claim about the world, and what was verified is a claim about
one build. On an old CLI those two come apart, and the reporter's case is a good
illustration: 0.2.1 bundled a 9,562-byte skill, main had 15,126, and the
installed skill documented a --full-page flag that their own CLI didn't
support. Doctor said everything was fine.

That matters more than a normal wording nit because doctor is the first thing
an agent runs, and an agent that's told its instructions are current will go
ahead and follow them.

What I changed: when the check would previously report plain ok, it now
consults the update cache, and if a newer bsk is already known it returns a
warning that names both versions and points at bsk update.

A few things I deliberately didn't do.

I wanted to rename the check to something like "agent skill matches this bsk
build", which says what's actually compared. I didn't, because CheckResult
derives Serialize and name goes out in bsk doctor --json, so anything
matching on that string would break. The comments around ok vs status and
the na variant made it pretty clear this file treats its JSON shape as a
contract, so I left the name alone and changed the verdict instead.

I used warn rather than fail, because the skill genuinely is synced
correctly for the binary that's installed — nothing is broken, it's just older
than the user probably assumes. warn also keeps ok: true, so this can't flip
anyone's exit code.

I didn't add a network call. print_update_hint_from_cache already reads
~/.bsk/update-check.json read-only and offline, with the daemon as the only
writer, so I reused that path via a small cached_newer_version helper. It
keeps the existing freshness rule, which I think is the right default here: a
missing or stale cache reads as "don't know", and doctor stays quiet rather than
claiming the skill is stale when it can't tell.

And this doesn't compare anything against upstream main — it only tells you
your CLI is behind, which is the actual root cause of a stale bundled skill. The
version-stamping idea in the issue would go further, but that's a bigger change
and I'd rather not fold it into this one.

The one thing I'm unsure about is the wording of the detail line. It currently
reads ...; matches the skill bundled with bsk X, but bsk Y is available, which
is accurate but long next to the other checks. Happy to shorten it if you'd
prefer.

Tests: three added in doctor.rs — that both previously-ok shapes (updated
and up_to_date) warn when a newer version is known, that None still reports
ok with no hint, and that a newer version doesn't downgrade a sync failure out
of fail. The existing skill_check_from_report callers pass None; I made
the newer version a parameter rather than reading the cache inside, so the tests
stay off the filesystem.

Verified with the commands CI runs: cargo fmt --all -- --check and
cargo clippy --workspace --all-targets --locked -- -D warnings are both
clean, and cargo test --workspace --locked --no-fail-fast goes from 708
passed / 1 failed to 711 passed / 1 failed — the three new tests, and the same
single failure before and after.

That one failure is skill_install::sync::tests::sync_continues_on_partial_error
and it's my environment, not your tree: it chmods a directory to r-x to force
a write error, and I'm running as root, which ignores the permission bits, so
the write succeeds and Codex ends up in updated. It fails the same way on a
clean checkout with my change stashed. Worth knowing if anyone else ever runs
the suite in a container as root.