tasks: pmcp documents ttl/poll_interval in seconds but forwards them unchanged; MCP defines both in milliseconds #330

Found while planning #298 (plan PR #329).

What

The MCP 2025-11-25 spec defines TaskMetadata.ttl and Task.pollInterval in milliseconds. pmcp's docs and the tenant contract describe task.ttl / task.poll_interval on gateway.invoke in seconds, and pmcp forwards the number unchanged. So a caller asking for ttl: 300 (5 minutes, per pmcp's docs) gets a 300 ms retention from a spec-conforming downstream; reported pollInterval values are likewise read as seconds when they are milliseconds.

To decide

• Which unit the gateway's own API uses (keeping seconds and converting at the boundary is least disruptive to callers; switching to milliseconds matches the spec but breaks the documented contract).
• Conversion in both directions (outbound ttl, inbound ttl/pollInterval in task info), with the bounds task.ttl accepts negatives and task.poll_interval accepts NaN/Infinity (forwarded downstream) #298 sets expressed in the chosen unit.
• Docs, the tenant contract, CHANGELOG (a behaviour change for any caller relying on today's pass-through).

Repro

Call gateway.invoke with task: {ttl: 300} against a downstream that honours the spec and observe the task expire after 300 ms.

See #298, #329.