Applying a new feature view through a client whose online store is
`type: remote` leaves it unwritable: the feature view reaches the registry,
but no table is provisioned server-side, so the write that `feast materialize`
performs returns HTTP 500 with `no such table`.

The existing test_remote_online_store_read_write does apply a feature view
through a remote client and write to it, but it applies `driver_hourly_stats`
-- a name the server already provisioned during its own `feast apply` at
setup. The table exists before the client touches it, which masks the bug.
This test applies a feature view the server has never seen.

The assertion is on the user-visible contract (a feature view applied through
a remote online store must be writable) rather than on any particular
mechanism, so it holds regardless of how the fix is implemented.

Refs feast-dev#6693

Signed-off-by: Rishabh <158596025+RishabhCodezZz@users.noreply.github.com>

Review follow-ups on the remote online store provisioning endpoints.

/update-infra and /teardown-infra asserted permissions on the feature views
in the request body but not on the entities, so a caller could provision or
drop entity infrastructure without an authorization check. Both endpoints now
apply the same CREATE and DELETE actions to entities that they already apply
to tables.

_infra_object_types() re-ran its five lazy imports on every call, and
encode_infra_object() invoked it twice per object across four lists. It is
now cached and read once per call.

The integration test proved that apply() provisions a table but never
exercised the teardown path, and both of its fixtures leaked their temp
directories. It now asserts against the server's own SQLite file on both
sides of the lifecycle -- the table exists after apply and is gone after
teardown, which covers /update-infra and /teardown-infra end to end -- and
removes its temp directories on the way out.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: Rishabh <158596025+RishabhCodezZz@users.noreply.github.com>

Security fix found in review of the /update-infra and /teardown-infra
endpoints added in bd367e4.

`decode_infra_object()` called `from_proto()` on client-supplied
protobuf bytes without `skip_udf=True`. For StreamFeatureView, that
means `dill.loads()` runs on the embedded UDF body; for
OnDemandFeatureView with a pandas transformation, `resolve_udf()`
runs `exec()` on the UDF source text. Both are documented elsewhere
in this codebase as safe only for trusted registry content --
registry_server.py passes `skip_udf=True` in every place it decodes
a client-submitted proto for exactly this reason. These two new
endpoints decode a raw HTTP request body from an authenticated but
untrusted client, so neither unpickling nor exec'ing it is safe.
Confirmed exploitable: a crafted StreamFeatureView proto with a
poisoned pickle payload, and a crafted OnDemandFeatureView proto
with a malicious body_text, both run arbitrary code during decode,
before authorization is checked and independent of whether the
proto is otherwise valid.

`_infra_object_types()` now records which of the five object kinds
carry a UDF, so `decode_infra_object()` cannot decode one without
passing `skip_udf=True`. Provisioning only ever needs schema and
metadata, never the transformation itself, so this has no functional
cost. Two regression tests prove both vectors are closed -- each
fails against the pre-fix code and passes against the fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Rishabh <158596025+RishabhCodezZz@users.noreply.github.com>