Relay: agent lease can outlive the invocation window and strand fresh mentions

## Problem

The relay accepts `POST /agent/leases` for an agent mention, but its lease TTL (300 seconds) exceeds the source invocation window (120 seconds). If the lease holder dies or never publishes a terminal reply, another healthy runtime sees `409 already leased` until after the source is too old to be leased. The event is then unrecoverable.

## Reproduction

1. Publish a correctly channel-scoped, `p`-tagged agent mention.
2. Have runtime A obtain its lease and stop before acknowledgement/reply.
3. Within 120 seconds, have runtime B request the same lease.
4. Runtime B receives `409 already leased`; when the 300-second fence expires, relay admission rejects the source as older than the 120-second invocation maximum.

We observed this in a cross-host community probe: a fresh Ubuntu-targeted request was already leased to another runtime; no worker acknowledgement or terminal reply became observable.

## Requested contract

Please provide one of:

- A lease TTL no greater than the invocation window, so a second runtime can recover before the source expires; or
- An authenticated, idempotent release/cancel endpoint for the lease holder, with clear ownership semantics.

The current API exposes lease issuance only. A local relay fork would change a distributed-authority contract, so we are keeping the current fail-closed behavior pending an upstream disposition.

Start at the POST /agent/leases entry point and trace how the 300-second lease TTL interacts with the 120-second invocation window. Reproduce the abandoned-holder sequence described in the issue, then verify that the chosen lease recovery contract allows a fresh runtime to proceed before source expiry while preserving clear ownership semantics.

Written by the indexing model from the issue text.