chore: bump mech-interact to v0.32.4

[DIvyaNautiyal07]

Summary

• Repins mech_interact_abci to the v0.32.4 release hash (bafybeici5tsg...), propagated to the agent, services, and dependent skills via autonomy packages lock.
• v0.32.4 removes the dedicated RESPONSE_ROUND_TIMEOUT event (reverting to the shared ROUND_TIMEOUT), so trader_abci/fsm_specification.yaml is regenerated: (MechResponseRound, ROUND_TIMEOUT) -> HandleFailedTxRound.
• Moves the upstream_pins entry in pyproject.toml from v0.32.4-rc2 to the final v0.32.4 tag.
• Drops the explicit use_dynamic_mech_selection: false overrides from the flag-off configs (trader_abci/skill.yaml, trader_pearl and polymarket_trader service.yamls). main never sets this key, so the overrides added by the off-chain wiring silently flipped the effective value from the mech-interact default (true) to false. Removing them restores main parity.

Timeout wiring is unchanged: MechInteractEvent.ROUND_TIMEOUT still maps to mech_interact_round_timeout_seconds (5400s), which satisfies the new off-chain poll-budget guard (needs >= 330s).

Test plan

• check-hash, check-packages, check-dependencies, check-third-party-hashes, uv lock --check
• check-abciapp-specs (regenerated FSM), check-abci-docstrings, check-handlers
• black / isort / flake8 / mypy / pylint / darglint / bandit
• check-doc-hashes, gitleaks
• py3.12-darwin: 4173 tests pass

🤖 Generated with Claude Code

[OjusWiZard]

Verified end-to-end: hash propagation is consistent across all 10 files and matches upstream v0.32.4; the regenerated FSM edge (MechResponseRound, ROUND_TIMEOUT) → HandleFailedTxRound keeps the same target as before (only the event name changed) and handle_failed_tx.py already special-cases mech timeouts into the blacklisting path; no stale RESPONSE_ROUND_TIMEOUT/rc references remain at PR head.

On the use_dynamic_mech_selection removal — confirmed the PR's claim directly against main: main never sets this key in trader_abci/skill.yaml or either service.yaml, and polymarket_trader on main already ships the identical valid_mechs allowlist, so the effective true default is proven production behavior, not new exposure. For trader_pearl the flip is a no-op (use_mech_marketplace: false).

Two non-blocking suggestions:

1. Nothing in the test suite pins the resolved mech_marketplace_config for either service — a small resolution-level test (mirroring test_agent_config_resolution.py) asserting use_dynamic_mech_selection is absent/true would catch a future accidental re-introduction of the override in CI rather than via production drift.
2. Description nit: MechResponseRound's effective timeout moves from the rc2-era ~330s to 5400s (restoring main behavior, since the dedicated event never accepted overrides in composed apps). Worth a line since "timeout wiring is unchanged" holds vs main but not vs the rc2 base.

🤖 Reviewed with Claude Code

[bennyjo]

One deployment question — pin and FSM regen otherwise verified clean against the v0.32.4 tag.

[OjusWiZard]

Approving. No new commits since review; the remaining open thread is @bennyjo's MECH_MARKETPLACE_CONFIG env-divergence question, which Divya's deployment-path analysis answers (Pearl constructs the config from scratch; no env cleanup needed) — leaving that thread to him to close.

[bennyjo]

Re-review: pin + FSM regen + use_dynamic_mech_selection override removal all verified clean against v0.32.4; full CI green at head. My earlier MECH_MARKETPLACE_CONFIG env-divergence question is answered (Pearl builds the config from scratch, no env cleanup needed). Approving.