send an idempotency key on lease extend

[bpapillon]

The lease wire client already let the generated credits client retry acquire and extend under the default policy, and extend carried no idempotency key, so a 502 arriving after the server committed the growth would grow the lease twice. The API now accepts an idempotency_key on extend (schematic-api #8556); acquire has always handed back the slot's existing active lease.

Extend now mints one UUID per call and sends it as the key. The retry loop resends the same body, so every attempt of one extend collapses to a single grow while a later extend gets its own key. The check-and-reserve path still carries no key and keeps its no-retry setting.

Tests drive the generated client over a mock transport that replays 502 then 200: extend sends the same key on both attempts and the manager applies the response once, acquire installs the lease from the 200, and two extends carry different keys.