Feature: Immutable registry fee share per registry

**What**

Make registry fee share immutable per registry deployment. Currently each `Subscription` stores its own `registryFeeShare` because registry owners can change the share via `setRegistryFeeShare`. When the share changes, renewals that cannot extend in-place increment the nonce — adding loop iterations.

If registry fee share were immutable, claim logic could reference a single registry-level value instead of iterating per-subscription entries, potentially reducing time complexity from `O(n)` to `O(1)`.

**Why**

`_claimable` loops from `claimedAtNonce` to `nonces[subscriber] + 1`, processing each subscription entry individually because price and registry fee share may differ per nonce. Immutable registry fee share (combined with immutable subscription price) could allow collapsing or skipping the per-nonce loop entirely — a significant gas reduction.

Trade-off: registry owners who need a new fee share must deploy a new registry. Existing assets would need to be transferred or re-registered under the new registry, requiring additional design thought.

**How**

- Evaluate making `registryFeeShare` an `immutable` constructor parameter on `AssetRegistry`.
- Remove per-subscription `registryFeeShare` from the `Subscription` struct if a single registry-level value suffices.
- Redesign `_claimable` to avoid per-nonce iteration when price and fee share are constant across all subscriptions for a subscriber.
- Define migration path for existing registries and assets bound to mutable fee shares.
- Document operational flow when a registry owner needs a new fee share (new registry deployment + asset transfer/re-registration).
- Quantify gas savings with benchmarks comparing `O(n)` loop vs. `O(1)` claim path.
- Coordinate with immutable subscription price work (#143) since both immutabilities may be required for full loop elimination.

**Acceptance Criteria**

- Design proposal documents immutable registry fee share with clear trade-offs.
- Analysis shows path from `O(n)` to `O(1)` claim complexity when both price and fee share are immutable.
- Registry owners who need a new fee share have a documented path (new registry + asset migration).
- Gas benchmarks quantify savings under realistic subscription histories.
- Compatibility/migration strategy for existing deployments is documented.

Start by reading AssetRegistry, the Subscription struct, and _claimable, then compare the related immutable subscription price work in issue #143. Develop the immutable fee-share design, including existing-deployment migration and new-registry operational flow. Done means the proposal documents trade-offs and compatibility, shows the O(n) to O(1) path, and includes realistic gas benchmarks.

Written by the indexing model from the issue text.