test: bump 10s timeouts that flake on Flat DB CI

[LukaszRozmej]

Changes

• RpcTest.TestSerializedRequest: bump cancellation token from 10s → 30s. Under TEST_USE_FLAT=1 engine_newPayloadV5 + JSON serialization can exceed 10s, throwing TaskCanceledException (e.g. NewPayloadV5_rejects_invalid_BAL_early(...,SurplusReads) 15s).
• executePayloadV1_accepts_already_known_block: bump [CancelAfter(10000)] → [CancelAfter(30000)]. Same root cause — flat DB block production is just slower.

Both tests still complete well under 10s when not under CI load. Verified locally with TEST_USE_FLAT=1:

• 4/4 V1 known_block cases pass (7s 113ms)
• 32/32 V6 BAL early-reject cases pass (10s 066ms)

Types of changes

What types of changes does your code introduce?

• Bugfix (a non-breaking change that fixes an issue)
• New feature (a non-breaking change that adds functionality)
• Breaking change (a change that causes existing functionality not to work as expected)
• Optimization
• Refactoring
• Documentation update
• Build-related changes
• Other:

Testing

Requires testing

• Yes
• No

If yes, did you write tests?

• Yes
• No

Documentation

Requires documentation update

• Yes
• No

Requires explanation in Release Notes

• Yes
• No

[claude]

Claude finished @LukaszRozmej's task in 1m 3s —— View job

---

Review

• Read changed files and diff
• Review for correctness, edge cases, regressions
• Check adherence to repo rules
• Post final review

---

This is a focused, minimal fix for CI flakiness under TEST_USE_FLAT=1. Both changes are correct and the root cause explanation is clear. No production code is touched.

Finding: Low — TestSerializedRequest timeout is now global (30s affects all 150 callers)

RpcTest.TestSerializedRequest is a shared utility called by ~150 tests. The 10s CTS was a safety net against hangs or runaway serialization in any of those tests. Tripling it globally means a hung/deadlocked test will now run for 30s before failing. In practice this is unlikely to matter much (these are unit tests, not health checks), and the flat DB serialization genuinely needs the headroom — so this is acceptable.

Finding: Low — potentially missed sibling timeout

EngineModuleTests.PayloadProduction.cs:108 has [CancelAfter(10000)] on getPayloadV1_picks_transactions_from_pool_v1. If flat DB block production also slows that test, it could flake for the same reason. Worth keeping an eye on; it's not blocking this PR if the test hasn't flaked yet.

---

No critical, high, or medium findings. The fix is correct and proportionate to the problem. Mergeable.