context warns the notes mirror is unfetched in a repo where no notes ref exists anywhere, and doctor --fix reports ok while the ref stays absent

[MongLong0214]

What happened

In a repository where no notes ref exists anywhere — not locally and not on any remote — every
commitlore context call is prefixed with a warning that its answer may be incomplete, and points at
a fix that cannot change anything:

$ commitlore context Sources/LogicProMCP/State/StatePoller.swift
commitlore: the notes mirror has not been fetched here, so this answer may be missing records that
exist upstream (git fetch does not fetch refs/notes/commitlore by default).
fix: commitlore doctor --fix, then git fetch
no active records for … — but the notes mirror has not been fetched here, so this is not the same as
"none exist" (commitlore doctor --fix)

But there is nothing upstream to fetch:

$ git ls-remote origin 'refs/notes/*'
(empty)
$ git rev-parse --verify refs/notes/commitlore
(fails — ref absent)

And doctor --fix reports both related checks as ok while the ref stays absent:

ok  notes fetch refspec — git fetch succeeds for fork, origin, … and covers refs/notes/commitlore
ok  notes push — no local mirror yet — nothing to push

Why it matters

The warning is the one thing that tells a caller whether "no records" means "none exist" or "you
haven't looked". When it fires in a repo that provably has no notes anywhere, it trains the reader to
ignore it — and it is the same sentence that would appear in the case where records really are
missing.

Also observed

The warning cleared only after running commitlore doctor --fix twice. After the first run the
ref was still absent and context still warned; after the second, context stopped warning while the
ref was still absent. So whatever state the warning keys on is set by the second invocation rather
than by the condition it describes.

Suggestion

Distinguish "no mirror has been fetched" from "no mirror exists to fetch". When git ls-remote shows
the remote carries no refs/notes/*, the honest answer is that there is nothing upstream, and the
records shown are complete — not that the answer may be missing something.

Environment

• commitlore 0.7.1
• git 2.50.1 (Apple Git-155)
• macOS, repository with 942 commits, 14 of them carrying CommitLore-Version: trailers

[MongLong0214]

Fixed on dev in #531. Merged to dev, unreleased.

The read path was answering the wrong question. It asked what the clone intends to fetch — git config — and treated a covering refspec as proof a remote had been consulted. It never has been: doctor --fix writes the refspec and fetches nothing, so a repository that has never spoken to its remote looked exactly like one that had and found nothing.

The probe moved to where a network call belongs. doctor --fix asks each remote what it advertises and records the answer bound to that remote's configured URL; the query path reads that local observation and makes no round trip before an edit. A changed URL invalidates the evidence rather than inheriting it.

Three states now stay apart, and the third is the one that had to survive:

state	result
mirror present here	answers for itself
recorded observation: every remote advertised none	an empty answer is a true empty
no observation, unreachable remote, or a refspec that does not cover the mirror	keeps warning

Turning "I could not check" into silence would have been a worse bug than the one reported.

A repository with no remote at all is a true empty, not an unknown — there is nowhere for an unseen record to be, and no probe could ever settle it, so warning there would be permanent and about nothing. The first pass got that wrong in the other direction and it was corrected before merge.

Limit: the observation is as old as the last doctor --fix. A mirror pushed upstream after it is not visible, and an empty answer reads as a true empty until the next probe.