Fix CallLogSummary desync, double real invoke, per-caller rate-limit pruning, add args cap (#1193-#1196)

[icentedward76-sketch]

• bug(router-middleware): configure_route wipes CallLog without clearing CallLogSummary, reintroducing the #812 desync #1193: `configure_route` unconditionally wiped and rebuilt `CallLog` on every call regardless of whether `log_retention` changed, and never touched `CallLogSummary` at all — reintroducing the exact bug(router-middleware): reset_route_call_log clears entries but leaves CallLogSummary stale #812 desync through a different entry point. Now only wipes when `log_retention` actually changes, and does so via `call_log::clear` (the same fix `reset_route_call_log` already uses) so both `CallLog` and `CallLogSummary` stay in sync.
• bug(router-execution): execute()'s simulate_first invokes the target function for real twice, not once #1194: `execute()`'s `simulate_first` path invoked `dry_run_invoke` (a real `try_invoke_contract` call, not a side-effect-free preview — there's no such thing at the contract level) once for the "simulation" and again as the retry loop's first attempt, genuinely executing the target function twice. The simulation's result is now carried into the loop as attempt Add inline doc comments to all public contract functions #1 instead of re-invoking.
• security(router-execution): ExecutionRequest.args and simulate()'s args have no size limit unlike router-multicall's MAX_ARGS_PER_CALL #1195: neither `ExecutionRequest.args` nor `simulate()`'s `args` had any length limit before reaching `try_invoke_contract`, unlike the sibling `router-multicall` contract's existing `MAX_ARGS_PER_CALL` guard. Added the same constant (20) and an `ArgsTooLarge` error variant, checked in both `execute()` and `simulate()`.
• bug(router-middleware): prune_stale_rate_limits uses the route's base window, ignoring longer per-caller override windows #1196: `prune_stale_rate_limits` pruned every caller in the map against the route's own `window_seconds`, even callers with a per-caller `CallerRateLimitConfig` override configuring a longer window — evicting their rate-limit state (and silently resetting their call count) long before their real window elapsed. Now resolves each caller's effective window (their override if set, else the route's base window) before deciding staleness.

Closes #1193
Closes #1194
Closes #1195
Closes #1196

[drips-wave]

@icentedward76-sketch Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits