Function claims_press 

pub fn claims_press(
    handlers: Option<&SceneItemHandlerSet>,
    flags: ItemFlags,
) -> bool

Whether an entry would act on a press — the occlusion rule of this module, in one predicate.

True when the item is IS_DRAGGABLE, or carries a handler that a press is the beginning of: on_tap, on_double_tap or on_context_menu. False for everything else.

Read at exactly one place — the above-a-card veto that decides whether the lightweight tier may take a press away from a heavyweight card. Not band-scoped: it compares whole PaintKeys per child, so an Interleaved claimant vetoes the cards it is painted over too. Everything else in the scene still resolves the topmost entry and consults its handlers afterwards.

Why a hover affordance is not a claim

on_hover, cursor and tooltip are hover affordances, and a hover affordance does not take a press. Counting one as a claim is not a conservative over-approximation, it is a click-swallower: the veto removes the card from the arena’s walk, the view becomes the target, and the tap then resolves to an item that has no on_tap — so the press reaches nobody, silently. A corkboard that adds a .tooltip(..) to an Over hint region would make every note beneath it un-clickable, un-focusable and un-editable by mouse.

All three keep working, and they never needed the veto to: the view’s own hover seam runs in the preview pass, which fires on every strict ancestor of the target, so it reaches the item whether a card won the walk or not. The cursor is the one that has to be arbitrated rather than merely allowed, and it is — by the SceneView’s cursor rule (an Over item’s declared cursor wins, silence otherwise), not by taking the card’s press away.

accepts_drops is not a claim either, for the same reason in the other direction: a drop is the release of somebody else’s drag, not a press on this item, and nothing in the crate routes a drop through this predicate.