Feature: Introduce asset abstraction for pluggable subscription models

**What**

Introduce an Asset abstraction layer to support multiple `IAsset` implementations beyond the current single model.

The new direction should support subscription models based on arbitrary on-chain state, oracle responses, and other mechanisms (not only permit-based ERC20 flows).

Key design changes:

- change subscription entrypoint to:
- `subscribe(subscriber, bytes calldata data)`
- deserialize `data` with `abi.decode` inside specific implementations to parse required inputs
- create an abstract Base Asset contract containing common/shared logic
- allow implementers to provide custom cancellation logic by enabling `cancel` overrides
- keep Permit-based ERC20 Assets as default implementation

**Why**

Current single-implementation assumptions limit extensibility and force all subscription types into one flow. A pluggable abstraction enables new asset types and subscription mechanics without repeatedly modifying core contracts.

**How**

- Refactor interfaces/contracts to support generic subscription input via `bytes data`.
- Define a robust abstract Base Asset contract with reusable/common behaviors.
- Move implementation-specific logic (validation, decoding, authorization, settlement rules) into concrete asset implementations.
- Mark cancellation paths as override-friendly so implementations can enforce model-specific cancellation behavior.
- Ensure default Permit-based ERC20 asset remains available and backward-compatible where feasible.
- Add tests for generic subscribe decoding, base contract invariants, override behavior, and multiple asset implementation scenarios.
- Document expected encoding formats and integration expectations for each asset type.

**Acceptance Criteria**

- Asset architecture supports multiple implementations with distinct subscription models.
- `subscribe(subscriber, bytes calldata data)` is available and exercised by tests.
- Abstract Base Asset contract provides shared behavior used by concrete assets.
- Custom cancellation logic can be implemented via overrides safely.
- Default Permit-based ERC20 asset continues to operate as the baseline implementation.
- Documentation explains data encoding/decoding and extension patterns.

**Estimation**

**Dependencies**

- #109

Start by reading the existing IAsset and Permit-based ERC20 asset contracts, then trace the current subscription entrypoint and cancellation paths. Define the shared responsibilities for Base Asset and the data encoding expected by concrete implementations. Done means multiple asset models can subscribe through bytes data, custom cancellation overrides are safe, the default ERC20 flow still works, and tests and documentation cover the extension pattern.

Written by the indexing model from the issue text.