after_moving (Pull and Update's shared machinery) gated a post-pull build
on `pulled || is_stale(None)` and then, once open, `claim(&mut inner,
None)` -- which marks every component with a build command regardless of
whether it was the one that moved. `trigger_if_needed(None, ...)` had the
same shape one level up: check is_stale, then hand off to build_now, which
is unconditional by design. So any pull that fetched anything rebuilt
every sibling beside the one that actually changed -- "it tries to update
the compose apk even if nothing was done."
`claim` now takes `only_stale`: false for build_now (a person pressed a
specific button, and staleness has no business overruling that), true for
trigger_if_needed and for the build after_moving runs after a pull.
component_is_stale was already scoped correctly per component; the bug was
building past that answer once any one component tripped it.
MismatchedPairNote also had its own word for the same "behind" freshness
freshnessNote already calls "out of date" -- "older than this build" was a
second name for one measurement, which is what "pulling says something
weird about the compose apk" turned out to be. Reused the existing word.
Regression test: a_pull_touching_one_component_does_not_rebuild_its_sibling.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
irisandClaude Sonnet 5
c41c36f25d