Review follow-up on 2bc624f:
1. finalSubmitTargets' payment-word block only covered PAYMENT_MARKERS
(立即支付/确认支付/输入支付密码). The ticket also requires blocking 去支付
and 付款. These cannot join the shared PAYMENT_MARKERS list: it also
gates the global pageProblem() payment guard, and UNPAID_MARKERS' "待付款"
contains "付款", so adding it there would misclassify every ordinary
unpaid-order page as a forbidden payment page. Added a separate
SUBMIT_TARGET_BLOCKED_MARKERS list (立即支付/确认支付/去支付/付款/输入支付密码)
used only by finalSubmitTargets' bottom-node subtree check.
2. Candidates were previously scanned across the whole snapshot, so an
unrelated clickable node outside the recognized panel (e.g. an
underlying goods-detail-page bottom bar still in the accessibility tree
behind the sheet) could out-rank the real button by sitting lower on
screen. Added panelContainerBounds(): climbs from the panel's unique
quantity input to the largest ancestor that still does not cover the
whole screen (the same "does not cover the whole screen" bounded notion
#331 already uses for sharesBoundedPanelContainer/boundedScrollables),
giving the whole bottom-sheet container. ParsedPddScreen.specPanelContainer
(PddScreenParser's `panelScrollable`) was considered but is the wrong
notion here: it is only the inner *scrollable dimension list* used for
heading/option parsing, and in a real PDD sheet the address/payment/
submit rows sit outside it as structural siblings, not descendants -
using it would incorrectly exclude the real submit row in most panels.
A candidate belongs to the panel when its center point falls inside the
container's bounds (geometric containment, matching the existing
`inside()` convention in this file, not path prefix, since PDD's own
tree can place the submit bar as a structural sibling that is still
visually part of the sheet). When the quantity input is missing or not
unique, the container cannot be determined and finalSubmitTargets fails
explicitly (no target) instead of guessing.
Tests added to SpecPanelRecognitionTest: bottom node labeled "去支付" and
"付款" are blocked (distinct from the existing PAYMENT_MARKERS-triggered
PURCHASE_PAYMENT_FORBIDDEN cases, since neither word reaches the global
guard); a clickable node outside the recognized panel container is never
chosen even though it is bottom-most on screen; a recognized panel with no
determinable quantity input/container fails explicitly. All existing
readOrderResult tests (which legitimately show "待付款"/"去支付" on the
order-result page, unrelated to finalSubmitTargets) stay green unchanged,
confirming SUBMIT_TARGET_BLOCKED_MARKERS did not leak into that path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NTDbDcwbDw1TSAcE6wfh2F
