fix: engines default to no runtime cache; the module owns the implicit one

[tp5uiuc]

Description

What

An engine built without a TorchTensorRTModule came up with a path-string
runtime_cache and attached a cache nothing owned, freeing it out from under
the engine. Engines now default to no cache; the module owns the implicit one.

Why

RuntimeSettings.runtime_cache defaults to a path string, and
TorchTensorRTModule resolves it into a RuntimeCache it owns, so the compile
path is fine. An engine reached without a module -- built from packed engine
info, or loaded as a graph constant from a saved ExportedProgram -- never
passes through that resolver, so TRTRuntimeConfig wrapped the string in a
local, handed the live IRuntimeCache to the engine's IRuntimeConfig, and let
it be collected on return. The next createExecutionContext read freed memory.

The C++ runtime has no such path: RuntimeSettings::runtime_cache is an
intrusive_ptr defaulting to nullptr, with no string form to mis-own.

The module's post-load resets have to move with the engine, or the two disagree:
a module holding a stale path string lets a later runtime_config(...) block --
a call that need not mention caching -- resolve it and leave an autosaving handle
installed at the shared default path on exit.

How

• _TRTEngine.py: engines construct TRTRuntimeConfig with
  runtime_cache=None, matching the C++ default. RuntimeSettings()'s own
  default is unchanged -- that one belongs to the module, which pushes the
  resolved handle down in setup_engine.
• _TorchTensorRTModule.py: the set_extra_state / __setstate__ resets drop
  to runtime_cache=None so the module agrees with the engine it rebuilds; an
  empty-string runtime_cache normalizes to None so no string reaches an
  engine.
• _runtime_config.py: _apply_settings accepts only None or a
  RuntimeCache and raises TypeError on a string; TRTRuntimeConfig's own
  no-settings default follows suit. The docstring already claimed raw strings
  were not accepted here.
• Tests: module-less engines default to no cache, execute without one, accept an
  explicitly attached RuntimeCache, and reject strings; the compile path still
  builds and persists its implicit cache; the post-load resets leave no cache,
  and a cuda-graph-only context manager over a loaded module installs none on
  enter and leaves none on exit.

Testing

TensorRT-RTX on A100, tests/py/dynamo/runtime/ plus
models/test_runtime_cache_models.py:

Build	before	after
Python runtime	4 failed, 170 passed, 60 skipped	174 passed, 60 skipped
C++ runtime	4 failed, 171 passed, 59 skipped	175 passed, 59 skipped

The four failures before are the new tests themselves; each was confirmed
failing on the parent commit and passing here, on both builds. There are no
other failures on either build.

models/test_export_serde.py, test_cross_runtime_serde.py and
test_fallback_data_dependent_ops.py were run before and after on both builds
because the post-load resets sit on the torch.load / load_state_dict paths:
identical results either side, with the only failures (test_save_load_aoti,
test_save_load_ts) pre-existing and unrelated.

Save/load deployment was checked on both runtimes: the loaded engine runs with
no cache attached, and an explicitly attached RuntimeCache persists.

Cost / Gotchas

An engine used without a module now gets no runtime cache instead of an implicit
one, and neither do modules restored by torch.load / load_state_dict. No
configuration loses working behaviour: that path raised on the Python runtime,
already attached nothing on the C++ runtime, and never initializes a runtime
config on standard TensorRT. Callers wanting a cache there attach a
RuntimeCache explicitly.

Supersedes #4541 -- the TestPythonRuntimeAliasedIO failures it skipped are
fixed here rather than skipped.

Followups

runtime_config() / runtime_cache() locate engines via named_modules(), so
neither reaches an engine loaded as a graph constant. Attaching settings to a
saved-and-loaded program currently requires the engine API directly.

Restoring implicit caching to load_state_dict -- by re-applying the setter
after engine construction in set_extra_state, as setup_engine does -- is
deliberately left out; it changes C++-runtime behaviour too and wants its own
testing.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist:

• My code follows the style guidelines of this project (You can use the linters)
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas and hacks
• I have made corresponding changes to the documentation
• I have added tests to verify my fix or my feature
• New and existing unit tests pass locally with my changes
• I have added the relevant labels to my PR in so that relevant reviewers are notified

[cehongwang]

Overall OK

[cehongwang]

We probably want to destroy the self._live here because the initialization was not successful?

[tp5uiuc]

Good catch, done in cb95af3 by resetting the live and propagating the exception up the call stack. Thanks Adrian!