Feature: Immutable subscription price per asset

**What**

Make subscription price immutable per asset. Currently each `Subscription` struct stores its own `subscriptionPrice`, and when the asset-level price changes, renewals that cannot extend in-place increment the nonce — adding another entry to the claim loop.

If subscription price were immutable (set at asset creation, like `SUBSCRIPTION_DURATION`), asset owners could not increase loop size by changing price. To offer a different price, they would deploy a new asset.

**Why**

In `_subscribe`, when a subscriber renews but `subscription.subscriptionPrice != subscriptionPrice` (or payer/registry fee share differ), the nonce is incremented and a new subscription entry is created. Each additional nonce entry adds one iteration to `_claimable` and `_removeSubscription` loops.

Immutable subscription price removes one vector of nonce growth, keeping claim gas more predictable. This is a protocol design trade-off: simpler, cheaper claims vs. flexibility to adjust pricing on an existing asset.

**How**

- Evaluate making `subscriptionPrice` an `immutable` constructor parameter (mirroring `SUBSCRIPTION_DURATION`).
- Remove per-subscription `subscriptionPrice` from the `Subscription` struct if no longer needed.
- Simplify `_subscribe` extension logic — fewer conditions that force a nonce increment.
- Define migration path: existing assets with mutable price remain as-is; new assets use immutable price.
- Document that price changes require creating a new asset and migrating subscribers.
- Update tests and gas benchmarks to quantify loop reduction.
- Assess impact on `setSubscriptionPrice` and any registry/UI flows that depend on price updates.

**Acceptance Criteria**

- Design proposal documents immutable subscription price with clear trade-offs.
- Claim loop size cannot grow due to subscription price changes on a single asset.
- Asset owners who need a new price must create a new asset (consistent with duration immutability).
- Gas benchmark or analysis shows reduced nonce growth under typical renewal patterns.
- Migration/compatibility strategy for existing deployments is documented.

Start by tracing the Subscription struct and constructor alongside SUBSCRIPTION_DURATION, then inspect _subscribe, _claimable, _removeSubscription, and setSubscriptionPrice. Review existing tests and gas benchmarks for renewal and nonce growth. Done means the design, compatibility path, tests, gas analysis, and documentation cover immutable pricing for new assets while preserving existing deployments.

Written by the indexing model from the issue text.