fix: hydrate isActive from contract state in ocr_get_subscriptions fallback path

## Problem

When `INDEXER_URL` is not set, `ocr_get_subscriptions` builds the subscriber list from on-chain events (`SubscriptionAdded`, `SubscriptionRenewed`, `SubscriptionExtended`) and computes `isActive = endTime > now` from event data.

This is stale after a revoke. `Asset.revokeSubscription` trims the on-chain `endTime` but does not emit any of the three events the scan watches — it emits `SubscriptionRevoked`. The list tool therefore shows `isActive: true` for revoked subscriptions until their event-derived endTime naturally expires.

## What to do

After building the subscriber list from events, batch `isSubscriptionActive(bytes32)` calls using `multicall` to get ground-truth active status from the contract. Replace the locally-computed `isActive` with the contract result.

Optionally, also scan `SubscriptionRevoked` events to pre-filter the call set (skip subscribers that were revoked and haven't been re-subscribed since).

## Why

`ocr_check_subscription` is the authoritative single-subscriber check. `ocr_get_subscriptions` should be equally accurate for the full list. An operator revoking a subscription and immediately listing to confirm should see consistent results across both tools.

## Notes

- Multicall keeps this to a single RPC round-trip regardless of subscriber count
- This only applies to the event-scan fallback; the Ponder path (issue #1) handles this correctly already

Start by tracing the ocr_get_subscriptions event-scan fallback and compare its status handling with the authoritative ocr_check_subscription path. Use the SubscriptionAdded, SubscriptionRenewed, SubscriptionExtended, and SubscriptionRevoked events plus the isSubscriptionActive(bytes32) contract call as described; done means revoked subscriptions report the contract's active status and remain consistent with the single-subscriber check.

Written by the indexing model from the issue text.