[WP5] x402 permit-relay integration for Unity SDK (review + implement)

## Context

We built `open-creator-rails.x402-adapter` — a Hono service that lets users subscribe to an Asset without paying gas. The user signs an EIP-2612 permit; the Facilitator broadcasts the transaction.

Before you write any code, read the adapter first:

- [`open-creator-rails.x402-adapter/docs/architecture.md`](https://github.com/ChainSafe/open-creator-rails.x402-adapter/blob/main/docs/architecture.md) — how the flow works end to end
- [`open-creator-rails.x402-adapter/docs/ocr-permit-v1.md`](https://github.com/ChainSafe/open-creator-rails.x402-adapter/blob/main/docs/ocr-permit-v1.md) — the exact payload structure, subscriber ID derivation, and settlement logic
- [`open-creator-rails.x402-adapter/src/routes/settle.ts`](https://github.com/ChainSafe/open-creator-rails.x402-adapter/blob/main/src/routes/settle.ts) — what the Facilitator actually does on-chain

Then read the integration spec written for you:

- [`open-creator-rails.unity/docs/x402-integration.md`](docs/x402-integration.md)

## Your job

1. **Triage first.** Read the adapter code and the spec. If anything looks wrong, inconsistent with the Unity SDK's existing patterns, or underdefined — comment here before implementing. Push back on anything you disagree with.

2. **Implement** `X402PermitRelay.cs` and `X402Types.cs` in `Runtime/X402/` as described in the spec, once you're satisfied the design makes sense.

## Key things to verify before implementing

- The subscriber ID derivation in the spec (`Keccak256(abi.encode("ocr-permit-v1", address))` via `ABIEncode`) is intentionally different from `AddressToSubscriberId()` (the `encodePacked` variant). Make sure you understand why before using it.
- The permit structure (`spender = assetAddress`) is identical to the existing `Asset.Subscribe` flow — only who broadcasts changes.
- No new Unity package dependencies should be needed. Confirm `Nethereum.ABI` covers `ABIEncode` in your current version.
- The existing `Asset.Subscribe` direct flow must not be touched.

## What "done" looks like

- `X402PermitRelay.PayAsync()` completes a gasless subscribe via the Facilitator
- `X402Subscriber.DeriveSubscriberId()` produces the correct hash (a unit test would be ideal — cross-check against the TypeScript test in `open-creator-rails.x402-adapter/test/e2e/flow.test.ts`)
- Subscription active check after settlement uses the x402 subscriber ID

## Proof the adapter works

The adapter was verified end-to-end against a live Anvil chain before this issue was opened. Here is the exact output from running `npm run test:e2e:live` in `open-creator-rails.x402-adapter/`:

\`\`\`
=== OCR x402 Adapter — Local E2E Test ===

1. Loading deployments...
✓ Registry: 0xe7f1725E7734CE288F8367e1Bb143E90bb3F0512
✓ Asset: 0xcafac3dd18ac6c6e92c921884f9e4176737c052c (local_asset_1)
✓ Token: 0x9fE46736679d2D9a65F0992F2272dE9f3c7fa6e0
✓ Payer: 0x70997970C51812dc3A010C7d01b50e0d17dc79C8

2. Checking facilitator health...
✓ Facilitator at http://localhost:3402 is up

3. GET /supported...
✓ scheme: ocr-permit-v1, network: eip155:31337

4. Signing EIP-2612 permit...
✓ Token name: Test Token
✓ Permit nonce: 0
✓ Amount: 2 (1 period)
✓ Subscriber ID: 0xeb9ef709c623029c517421025898186957f7301b08098e8ff8783d0c27343e0e

5. POST /verify...
✓ isValid: true

6. POST /settle...
✓ success: true
✓ txHash: 0xef4bfc78a473d5f5b8d0fa5376ecf237f0baffb14e1fcb9c323620659762aac2

7. Checking on-chain subscription state...
✓ isSubscriptionActive: true

8. Idempotency check (second POST /settle)...
✓ returned same txHash — no double broadcast

=== All checks passed ===
\`\`\`

The subscriber ID `0xeb9ef709...` is the key reference value — your `X402Subscriber.DeriveSubscriberId()` implementation must produce this exact hash for the Anvil account[1] address (`0x70997970C51812dc3A010C7d01b50e0d17dc79C8`).