fix(breadcrumb): stop suppressing a close while the host reports open (#656)

[drmoisan]

Stop suppressing a breadcrumb close while the host reports open

Closes #656

Summary

BreadcrumbDropDownOpenCoordinator._closeCompleted is cleared only on the RequestOpen and
Invalidate paths. A host that becomes open again by any other route left the flag set, so the next
close request was suppressed even though the host was genuinely open.

CloseCore now reads the host's open state into a local declared before the lock (_sync) and
narrows the completed-close guard from if (_closeCompleted) to if (_closeCompleted && !hostOpen).

What changed

File	Change
QuickFiler/Viewers/BreadcrumbDropDownOpenCoordinator.cs	Hoists bool hostOpen = _host.IsOpen; above the critical section; narrows the guard; adds two XML doc remarks recording the new condition and why the read sits outside _sync.
QuickFiler.Test/Viewers/BreadcrumbDropDownOpenCoordinatorTests.Part3.cs	Adds CloseCore_AfterSuccessfulCloseAndHostReopen_ReachesHostCloseAgain.

No other production, test, project, or package file is touched.

Why the host read is outside the lock

SR-4 of issue 501 declined this same refinement written as a read taken inside lock (_sync),
because that adds a foreign call made while the coordinator lock is held. Hoisting the read leaves
the count of such calls unchanged, so the design objection recorded there is respected rather than
reopened. The one pre-existing in-lock _host call at RequestOpen is untouched, and no new one is
added.

Reachability

This is latent-correctness hardening of a seam contract, not a repair of an observed user-facing
failure. The severity recorded on the issue (Medium, latent) is unchanged.

The picture is more precise than the issue text suggests, and the two analyses produced during this
work each covered only part of it. Both were re-derived against source before merge:

• BreadcrumbDropDownHost.Close returns true immediately after scheduling CompleteClose, and
  OpenState = false lives inside that scheduled callback. The scheduling chain ends at
  BreadcrumbPopupUiOperations.PostAsync, which delegates directly to BreadcrumbUiDispatcher.Dispatch.
• Dispatch runs the action inline and returns Task.CompletedTask when IsCurrentBoundary()
  is true. On the owner boundary — the normal path — CompleteClose therefore completes
  synchronously, OpenState is already false when Close returns, and the new guard behaves
  identically to the old one. On that path the change is a no-op.
• When IsCurrentBoundary() is false, Dispatch posts asynchronously, so Close can return true
  while OpenState is still true. The new branch is reachable there on the shipped host, with no
  substituted seam.

An exhaustive enumeration confirmed that no production path reopens the drop-down while bypassing
both RequestOpen and Invalidate: the only OpenState = true assignment is in
BreadcrumbDropDownOpenLifetime.ShowCurrentSurface, reachable only via RequestOpen, which clears
the flag immediately beforehand.

Risk direction: the narrowed guard can only let CloseCore proceed to _host.Close in the window
where the host genuinely reports open. It never suppresses a close that previously succeeded. Not
merge-method dependent.

Verification

Full C# toolchain, clean in a single pass:

Gate	Result
dotnet tool run csharpier check .	exit 0, 1566 files
msbuild TaskMaster.sln /t:Rebuild ... /p:EnableNETAnalyzers=true /p:EnforceCodeStyleInBuild=true	0 Error(s); warnings 5, unchanged from baseline
msbuild TaskMaster.sln /t:Rebuild ... /p:TreatWarningsAsErrors=true	0 Error(s)
Full MSTest suite with coverage	6926 / 6926 passed

Analyzer non-vacuity confirmed: zero Skipping target "CoreCompile" lines, so the changed files were
actually compiled by the gate.

Red-to-green: the new regression test was recorded failing before the production edit (with the
production file confirmed unmodified at that moment) and passing after it.

Coverage: repo line rate 0.853792 to 0.853732; the coordinator class 0.983122 to 0.983193, and both
changed lines carry hit counts of at least 1. This clears the CLAUDE.md floors (80 percent repo-wide,
90 percent new code) and also the 85/75 figures in .claude/rules.

Acceptance criteria

All 20 criteria in the feature spec.md are checked off and were independently re-verified from
primary evidence during review, not from the executor's summaries.

The three footprint criteria were re-measured with git diff --name-only origin/main...HEAD: under
QuickFiler/ and QuickFiler.Test/ the diff contains exactly the two files listed above, and it
contains no .csproj, .props, .targets, or packages.config path.

Review outcome

Policy audit, code review, and feature audit are committed in the feature folder. Blocking findings:
0 (0 FAIL, 0 blocking-PARTIAL). Seven non-blocking follow-ups are recorded as text in the feature
audit — chiefly amending the spec's reachability wording to match the analysis above, correcting a
description of the not-open Close branch, and adding a test harness variant that defers IsOpen
so the asynchronous timing is represented. They are deliberately not filed as issues from this
branch, which carries footprint acceptance criteria; the maintainer files one consolidated issue
after merge.

Note on the PR context bundle

The generated PR-context bundle in this run is unreliable and its output was not used for the
close list:

• It reports "GitHub CLI unavailable: GitHub CLI (gh) is not installed". This is false; gh is
  installed and working, and every issue number below was verified with it directly.
• Its author-asserted auto-close list contained four unrelated issues (462, 488, 500, 501) and
  twenty non-issue tokens of the form #AC-1 through #AC-20, scraped from the acceptance-criteria
  identifiers in spec.md.

Verified with gh: issues 462, 488, 500, and 501 are all already closed, so the scrape was
benign in this instance. Issue 656 is open and is this item's own issue. It is the only issue
this pull request closes.