DynamoDBOnlineStore has no plan() support, so feast plan never shows DynamoDB changes #6660

Is your feature request related to a problem? Please describe.

feast plan is meant to show what infrastructure would change before you apply it. For DynamoDB, it never shows anything, because DynamoDBOnlineStore doesn't override OnlineStore.plan() at all -- it just inherits the base class's default, which always returns an empty list:

def plan(
    self, config: RepoConfig, desired_registry_proto: RegistryProto
) -> List[InfraObject]:
    return []

Two other online stores (SqliteOnlineStore, MilvusOnlineStore) already override this and report real table changes. DynamoDB is a commonly used online store and doesn't get the same visibility.

Describe the solution you'd like

Add a plan() override to DynamoDBOnlineStore, plus a small DynamoDBTable InfraObject, so feast plan reports one table per feature view the same way SqliteOnlineStore.plan() does for SQLite. The InfraObject proto already has a CustomInfra field reserved exactly for this ("Allows for custom infra objects to be added" -- see protos/feast/core/InfraObject.proto), so this doesn't need any change to the core proto.

This only affects the feast plan reporting path. feast apply's diff-based apply path (FeatureStore._should_use_plan()) is currently gated to the local/sqlite provider only, so DynamoDBOnlineStore.update()/teardown() -- which already perform the real table creation/deletion today -- are completely unaffected either way.

Opened a PR with this fix: #6661. It also builds on the corrected feature-view-list pattern from #6659, which fixed a related bug (sqlite.py's plan() crashing on stream feature views, #6658) that this same code path would otherwise have inherited.

Describe alternatives you've considered

Leaving DynamoDBOnlineStore.plan() as the no-op default and not showing anything in feast plan for DynamoDB users -- current behavior, not desirable.

Additional context

We ran into the gap while evaluating a DynamoDB online store migration and building a custom store with plan() support outside the core repo; figured this specific piece (table-level plan reporting) is generally useful and small enough to contribute back directly.