web: composer context strip visibility is modelled in the parent, one flag per child #436

The shape of the problem

shouldShowComposerContextStrip (BranchToolbar.logic.ts:58) decides whether the composer context strip is visible by re-deriving, in the parent, whether each of its children will render:

hasActiveProject && (isGitRepo || showEnvironmentIndicator || hostsRestingComposerControls || hasCapacityReading)

One boolean per child, assembled in ChatView and passed down — a parallel model of what BranchToolbar actually draws. The two can drift, and when they do the failure is always one of two visible bugs:

• predicate says show, children render nothing → a visible empty bar (web: rollback on a Git project can render an empty composer context strip #435)
• predicate says hide, a child had content → hidden content (fixed in fix(web): keep the composer strip for a non-Git project's capacity reading #432)

Why it is worth changing

Both bugs above are the same bug from opposite directions, and each was found separately, months apart. The next item added to the strip — a token or context readout, a queue badge, anything — silently reproduces one of them unless whoever adds it also remembers to add a flag, wire it through ChatView, and cover it.

hasCapacityReading was added in #432 specifically because the capacity readout was the third kind of content and nobody had taught the predicate about it.

Possible directions

• Let BranchToolbar report its own emptiness upward. It already measures itself (stripElement, useLabelsOverflow), so it knows whether it rendered anything.
• Or collapse the strip from CSS on :empty / :has(), so emptiness is structural rather than modelled.

Either removes the parent's need to enumerate children at all.

Notes

Design/altitude issue rather than a live defect. Raised during review of #432 and deliberately left out of it to keep that PR to one concern.