Online read: columnar store return and proto-direct to_arrow to cut client CPU on wide reads #7072

Problem

For wide online reads against the Redis store (4 feature views, ~90 features, 100 to 500 entities per call) the fetch is now GIL-free with client: glide (#6870), but most of get_online_features wall time is still Python after the fetch:

• online_read returns one dict[str, ValueProto] per entity, built value by value.
• _get_online_features walks those into GetOnlineFeaturesResponse one value at a time.
• OnlineResponse.to_arrow() is pa.Table.from_pydict(self.to_dict()), so it costs more than to_dict, not less.
• get_feature_service(allow_cache=True) rebuilds the FeatureService from proto on every call, about 2 ms per request.

Measured locally (Apple silicon, Valkey 9.1, feast 0.67.0, 1500 entities x 11 feature views, service of 90 features from 4 views, p50 ms):

The fetch is about 17% of the SDK read. The same shape holds on the precompute_online=True fast path: one GET per entity, yet 34 to 72 ms at k=360 to 500 in an earlier run because response assembly dominates.

Proposal

1. An optional columnar return on OnlineStore, e.g. online_read_columns(...) -> dict[feature, list[bytes | None]] plus per-view timestamps, with the base class falling back to today's online_read. Redis can fill it straight from the pipeline replies with no per-value proto objects.
2. OnlineResponse.to_arrow() builds one pa.array per column from response.proto instead of going through to_dict.
3. Key the registry_proto_cache decorators in proto_registry_utils on the registry's version_id instead of id(registry_proto). Every registry refresh produces a new proto object, so today each refresh rebuilds every FeatureService from proto (about 35 ms for 14 services, most of it typeguard checks on Field.__init__), and get_feature_service has no object cache at all (about 2 ms per read).

A note on the tail: at k=500 the precompute_online fast path measured p50 63 ms with the default collector and 34 ms after gc.freeze(), because each read allocates tens of thousands of proto wrappers and trips gen2 collections. Not a Feast change, but worth a line in the feature server performance tuning guide.

Each is backwards compatible. I have working drafts of 2 and 3 (3 measured at 35 ms to 0.1 ms per refresh) and can open PRs if the direction is agreed. Fetch-side repro: see the script on #6856.