Duration weight

duration-weight v1: the longer it stays, the more it earns

A weight plugin for `staking-vault`. It reports a multiplier from a breakpoint table fixed at deploy: `bps[i]` applies once a stake has lasted `elapsed[i]` seconds. Below the first step the multiplier is 1.00x. The table has up to 16 steps; both columns are strictly increasing, and each multiplier is between 1.00x and 5.00x. The vault's own `maxMultiplierBps` still caps the result.

Ported from ENTITY's `StakeDurationMultiplier`, with a configurable table instead of constants.

- Time is read from the vault's `stakeInfo(id).since`, which resets on unstake. - If the token is not staked, or the vault cannot be read, the multiplier is 1.00x. `multiplierBpsOf` never reverts. - `_onInit` stores the vault address only and never calls it. In a recipe the vault is a predicted sibling deployed afterwards. - The vault adopts a new reading on `sync`. `refresh(ids)` forwards to the vault's permissionless `syncMany`. Between syncs a stake earns at its older, **lower** rate, never a higher one.

**Presets** (`DurationWeightPresets`): `gentle` (1d 1.10x, 7d 1.25x, 30d 1.50x, 90d 2.00x) and `steep` (1h 1.10x, 1d 1.50x, 7d 2.00x, 30d 3.00x), or a custom table in hours and percent.

**Roles:** the owner can only pause `refresh` and hand over ownership. **Locked:** `vault`, `elapsed`, `bps`.

**Value flows / fee lanes:** none. It holds no value.

**Gas:** a 16-step table read cold costs well under the 32k per-source budget of `composite-weight`. There is a test that runs four such sources inside the vault's 150k budget.

What if…

- **…I unstake and restake?** The clock starts over. - **…nobody syncs my NFT?** It keeps the last multiplier the vault recorded. Anyone can sync, and the site does it before claims. - **…the owner wants a different curve?** This one cannot change. A new vault and plugin would be needed.