DotGit.hasIncomingObjects lazily caches the result of an
incoming-dir scan in two struct fields (incomingChecked and
incomingDirName) without any synchronisation. Two goroutines
calling Object on the same *DotGit race on those fields; the
race detector reliably flags it under -race, with both a
read/write race on incomingChecked and a write/write race on
the cached name.

The bug was introduced in c7a4011 ("storage/dotgit: search
for incoming dir only once", 2018-08-25). *DotGit was
effectively single-threaded at the time, so the race stayed
latent for seven years. It surfaces under modern
parallel-reader patterns that funnel through getFromUnpacked
-> dir.Object -> hasIncomingObjects on cold startup.

Replace the two cache fields with a sync.Once plus the
cached name. sync.Once.Do provides the happens-before
guarantee the lazy init needs, so readers stay lock-free
after the first call. The loop body is preserved verbatim to
keep the existing selection behaviour (last lexical match
when multiple incoming directories coexist, which can happen
under concurrent git-receive-pack invocations).

Test: TestDotGit_HasIncomingObjects_NoRace launches 32
goroutines that all call Object against a fresh DotGit.
Clean under "go test ./storage/filesystem/dotgit/ -race
-count=10". Verified before this change that the same test
fails with the race detector on the buggy code.

Assisted-by: Claude Opus 4.7
Signed-off-by: Hidde Beydals <[email protected]>