fix(engine): Ur-Dragon softlock — propagate batched trigger subject count for EventContextAmount

[mike-theDude]

Closes #707

Summary

Fixes two related game softlocks:

Primary (#707): The Ur-Dragon's attack trigger (Whenever one or more Dragons you control attack, draw that many cards…) caused a stuck game. QuantityRef::EventContextAmount was resolving to 0 for batched triggers because extract_amount_from_event has no amount for AttackersDeclared events. A new current_trigger_match_count field on GameState carries the filtered subject count through resolution; EventContextAmount now checks this count first (CR 603.2c).

Scope expansion: A second priority softlock was found and fixed during investigation — under turn-control effects (CR 723, e.g. Mindslaver), handle_priority_pass was tracking priority_player (the rewritten submitter) instead of the semantic seat, so the "all players pass in succession" condition (CR 117.4) could never be satisfied.

Files changed

• crates/engine/src/types/game_state.rs — current_trigger_match_count field
• crates/engine/src/game/stack.rs — set/clear match count on batched trigger resolution
• crates/engine/src/game/quantity.rs — EventContextAmount precedence: match count → event payload → fallbacks
• crates/engine/src/game/trigger_matchers.rs — new: count_trigger_subjects_in_batch
• crates/engine/src/game/triggers.rs — propagate match count into stack entry clones
• crates/engine/src/game/priority.rs / turn_control.rs — semantic seat tracking for priority passing
• crates/engine/tests/integration/batched_trigger_subject_count.rs — 7 new integration tests
• crates/engine/tests/integration/turn_control_priority_softlock.rs — 2 new regression tests

CR references

• CR 603.2c — batched trigger fires once per batch; "that many" = filtered subject count
• CR 608.2c — optional sub-ability observes same trigger context
• CR 117.4 — all players must pass in succession for stack/phase advance
• CR 723 / 723.5 / 723.8 — controlling another player (turn-control seat ≠ priority_player)

Track

Developer

LLM

Model: claude-sonnet-4-6
Thinking: medium

Verification

• cargo fmt --all — clean
• cargo test -p engine — 8964 passed, 8 ignored, 0 failed

Scope Expansion

Turn-control priority softlock (CR 723) discovered during investigation of #707. Fixed in commit 58cea1754 with dedicated integration test turn_control_priority_softlock.rs.

Validation Failures

None.

CI Failures

None.

[gemini-code-assist]

Code Review

This pull request implements batched trigger subject counting (CR 603.2c), allowing "one or more" triggers to correctly resolve "that many" based on the number of matching subjects in a firing event batch. It introduces subject_match_count to tracking structures, implements the counting logic in trigger_matchers.rs, and ensures this count is saved and restored across optional effect decision points. Feedback focuses on a logic error in the state restoration during cost-payment continuations, missing mandatory CR annotations, and incomplete event coverage in the subject extraction logic.

[gemini-code-assist]

[HIGH] The logic to restore current_trigger_match_count is incomplete. While it correctly saves and restores the previous_trigger_match_count, it fails to assign the pending match count to state.current_trigger_match_count before draining the continuation. This breaks the "mirroring" mentioned in the comment and will cause EventContextAmount to resolve incorrectly (likely to None or 0) during the resumed resolution of a batched trigger with a cost (CR 603.2c, CR 608.2).

            let previous_trigger_event = state.current_trigger_event.clone();
            let previous_trigger_match_count = state.current_trigger_match_count;
            state.current_trigger_event = pending_event;
            state.current_trigger_match_count = state.pending_optional_trigger_match_count.take();
            effects::drain_pending_continuation(state, &mut events);
            state.current_trigger_event = previous_trigger_event;
            state.current_trigger_match_count = previous_trigger_match_count;

[gemini-code-assist]

[MEDIUM] Missing mandatory CR annotation for trigger_event_subject_ids. Per Rule R6, every rules-touching function must carry a CR <number> comment. This function implements the subject extraction logic required for CR 603.2c.

/// CR 603.2c: Subject ObjectIds carried by a single GameEvent for trigger filter matching.
fn trigger_event_subject_ids(event: &GameEvent) -> Box<dyn Iterator<Item = ObjectId> + '_> {

References

1. Every rules-touching line of engine code must carry a comment of the form CR : . ^(link)

[gemini-code-assist]

[MEDIUM] Poor sibling coverage for object-based events in trigger_event_subject_ids. While it handles attackers and zone changes, it returns an empty iterator for many other common events that can be subjects of "one or more" triggers (e.g., DamageDealt, TokenCreated, CreatureDestroyed, PermanentSacrificed, PermanentTapped, PermanentUntapped). This will cause EventContextAmount to resolve to 0 for batched triggers on these events (Rule L2). Note that for events like DamageDealt, you should also ensure unique ObjectIds are counted if multiple events in a batch target the same object.

[gemini-code-assist]

[MEDIUM] Use u32_to_i32_saturating for consistency with other quantity resolutions in this file (e.g., line 1203).

Suggested change

	.map(|n| n as i32)
	.map(u32_to_i32_saturating)

[mike-theDude]

All four Gemini review comments have been addressed in commit 08e45c7.

Comment #1 (HIGH — logic error in state restoration, engine.rs):
Added state.current_trigger_match_count = state.pending_optional_trigger_match_count.take(); immediately after state.current_trigger_event = pending_event; and before drain_pending_continuation. Without this, the resumed continuation saw None for current_trigger_match_count and EventContextAmount would fall through to the event-extracted or fallback value instead of the correct "that many" count.

Comment #2 (MEDIUM — missing CR annotation, trigger_matchers.rs:618):
Added /// CR 603.2c: prefix to the trigger_event_subject_ids doc comment. CR 603.2c confirmed via grep -n "^603.2c" docs/MagicCompRules.txt.

Comment #3 (MEDIUM — incomplete event coverage, trigger_matchers.rs):
Added explicit arms returning object_id for TokenCreated, CreatureDestroyed, PermanentSacrificed, PermanentTapped, and PermanentUntapped. Added a DamageDealt arm that yields the object ObjectId when the target is an object and an empty iterator when the target is a player (per CR 120.3 — player damage has no object subject). All six events were previously falling through to std::iter::empty().

Comment #4 (MEDIUM — use u32_to_i32_saturating, quantity.rs:1225):
Replaced .map(|n| n as i32) with .map(u32_to_i32_saturating) for consistency with the rest of the file.

Verified: cargo clippy --all-targets -- -D warnings (clean), cargo test -p engine (8956 passed).