Subscriber identity derivation differs from TypeScript SDK — cross-SDK subscriptions silently broken

## Summary

The Unity SDK derives subscriber IDs using a different encoding than the TypeScript SDK. Subscriptions created via one SDK cannot be resolved by the other.

## TypeScript SDK

`open-creator-rails.sdk/src/utils.ts`:

\`\`\`typescript
export function subscriberToId(subscriber: Address): Hex {
return keccak256(encodePacked(["address"], [subscriber]));
}
\`\`\`

This ABI-encodes the address as its 20 raw bytes, then keccak256-hashes them.

## Unity SDK

`io.chainsafe.open-creator-rails/Runtime/Utils/Extensions.cs`:

\`\`\`csharp
public static string Keccack256(this string value)
{
return Sha3Keccack.Current.CalculateHash(value).EnsureHexPrefix();
}
\`\`\`

Called in `OpenCreatorRailsService.cs` as:

\`\`\`csharp
byte[] subscriberHashBytes = subscriberId.Keccack256Bytes();
\`\`\`

`Sha3Keccack.Current.CalculateHash(string)` in Nethereum hashes the UTF-8 bytes of the string representation — i.e. the 42 ASCII characters of `"0x1a2b3c..."` — not the 20 raw address bytes.

## Impact

- A subscriber registered through the TypeScript web SDK produces a different `bytes32` ID than the same address hashed by the Unity SDK.
- `isSubscriptionActive` returns `false` for cross-SDK subscriptions.
- The failure is silent — no error, just wrong state.

## Protocol relevance

Subscriber identity derivation is the core primitive: `(subscriber, asset) → isSubscriptionActive`. All SDK implementations MUST use the same formula per `PROTOCOL.md §6.1`. This appears to be a FROZEN surface misalignment.