MOPS-1232 support configurable app_profile_id for online store - #48

Summary

Adds an optional app_profile_id field to BigtableOnlineStoreConfig, threaded through all four Bigtable data-access paths (sync read, sync write, async v1, async v2). Defaults to None, which preserves today's behavior exactly — requests continue to use Bigtable's default app profile when unset.

This unblocks routing specific workloads (e.g. a lower-priority/isolated consumer) through a dedicated Bigtable app profile — for priority (PRIORITY_HIGH/PRIORITY_LOW) and per-profile metrics attribution — without forking the online store.

Why this is safe — verified against the installed client

Checked against google-cloud-bigtable==2.31.0 (the version this repo already pins) that every parameter this PR adds is a real, existing kwarg on the underlying client — not something invented for this change:

• Sync client — Instance.table() already accepts app_profile_id:

  # google/cloud/bigtable/instance.py:649
  def table(self, table_id, mutation_timeout=None, app_profile_id=None):
      """
      :type app_profile_id: str
      :param app_profile_id: (Optional) The unique name of the AppProfile.
      """

• Table.__init__ stores it as self._app_profile_id (google/cloud/bigtable/table.py) and it's threaded into the built ReadRowsRequest/MutateRowsRequest at table.py:643, :736, :781, :1151.

• Async v1 client — BigtableDataClientAsync.get_table() documents the same parameter:

  # google/cloud/bigtable/data/_async/client.py:495
  def get_table(self, instance_id: str, table_id: str, *args, **kwargs) -> TableAsync:
      """
      app_profile_id: The app profile to associate with requests.
          https://cloud.google.com/bigtable/docs/app-profiles
      """

• Async v2 (raw proto) client — ReadRowsRequest has a first-class app_profile_id field:

  # google/cloud/bigtable_v2/types/bigtable.py
  class ReadRowsRequest(proto.Message):
      """..."""

So this PR is pure plumbing — passing a value Feast already had available (config.online_store) into parameters the client library has supported all along.

References

• Bigtable app profiles overview
• Create and configure app profiles
• Configure request priorities
• Terraform google_bigtable_app_profile
• Python Bigtable Instance.table()

Tests

• sdk/python/tests/unit/infra/online_store/test_bigtable.py (new) — mocked-client unit tests: config defaults to None, and each of the 4 call sites (online_read, online_write_batch, online_read_async, online_read_async_v2) receives the configured app_profile_id, parametrized over [None, "test-app-profile"].

• sdk/python/tests/integration/online_store/test_bigtable_app_profile.py (new) — emulator-backed round trip. Note: the Bigtable emulator has no concept of app profiles (no creation, no routing, no priority enforcement), so it can't validate server-side behavior. To still get a meaningful assertion, the test spies on the real Instance.table() (patch.object(..., side_effect=Instance.table)) to confirm our code actually threads the configured profile into the real client call, rather than only checking that read-after-write succeeds (which would pass even if the profile were silently dropped).

• tests/integration/feature_repos/universal/online_store/bigtable.py — BigtableOnlineStoreCreator gained an optional app_profile_id kwarg (unset by default), used only by the new integration test above; the existing universal online-store test matrix is unaffected.