batch-3: rate-limit scalability — widen max_tasks_per_24h (u8) and revisit per-agent counters vs economic limits

[7etsuo]

Context (found live 2026-07-05)

The dogfood loop hit the per-agent task rate limits in production. Investigation surfaced three layered constraints:

1. ProtocolConfig.max_tasks_per_24h is a u8 — the config dial can never exceed 255/day/agent regardless of policy intent.
2. update_rate_limits enforces a deliberate >= 1 floor ('prevents 0 = unlimited attack vector even with compromised multisig') — so the enforcement path's documented '0 = unlimited' semantics are unreachable via config. Good defense-in-depth, but it hard-codes the philosophy that per-agent counters must exist.
3. The counters are per-AGENT and agents are permissionless — an adversary sybils around them (registration stake is small), so they throttle honest high-volume creators (dogfood loop, future integrators like Axon, checkout-link SaaS volume) more than attackers.

Current mitigation: config raised to the legal max (cooldown 1s, 255/day, sig 4ajp8KzZ…) + the first-party loop rotates buyer agents.

Proposed batch-3 design work (needs a design doc + adversarial review, NOT a quick patch)

• Widen max_tasks_per_24h to u32 (layout impact: it sits mid-struct — needs the carve/migration treatment or a successor field in reserved space).
• Re-examine the premise: task creation already prices spam economically (escrow + rent + fees). Consider retiring per-agent creation counters entirely (keep DISPUTE limits — adversarial actions deserve throttles), or replacing the global cap with per-surface/operator policy.
• If counters stay: decide the compromised-multisig floor consciously (e.g. floor = 'cooldown >= 1s' only, cap floor removed) and document the threat model.

Refs: rate_limit_helpers.rs (0-disables semantics), update_rate_limits.rs:84-102 (floor), constants.rs defaults.