fix(executorch): lift nested and partitioner-excluded mutable buffers

[shoumikhin]

Depends on #4459. These fixes are on top of that branch, so the file diff here
includes its commits and CI will stay red until it lands. Only the final commit
(fix(executorch): lift nested and partitioner-excluded mutable buffers) is mine,
at +70/-7 across two files.

Overlaps #4472. That pull request fixes the same dotted-name buffer lookup against
main, standalone and with a test. This one carries the fix too, because #4459's branch
does not have it and the remaining fixes here would be unreachable without it. If #4472
lands first, drop that hunk from this one; if this lands first, #4472 becomes a no-op.
Either order works, they just should not both land unreconciled.

What this fixes

Four problems that stop a model from exporting when its caches live inside submodules, or
when part of the graph runs on a different backend. They are in one commit because they
block the same thing and are in the same function, and because the later ones only become
visible once the earlier ones are fixed.

1. A buffer owned by a submodule is skipped

A get_attr target is fully qualified, so a cache owned by a submodule arrives as
layers.0.self_attn.kv_cache.k_cache. Neither hasattr nor getattr walks a dotted path:

hasattr(gm, "layer.state")     # False, even though the buffer exists
gm.get_buffer("layer.state")   # the tensor

Every nested buffer is reported missing and skipped, so the copy-back path never runs. Any
real transformer owns its caches per layer, so this is the common case rather than an edge
case.

2. Renamed buffers leave the mutation targets dangling

register_buffer rejects dots, so a nested buffer is renamed to lifted_buf_*. The
recorded mutation targets keep the original dotted names, which no longer resolve:

SpecViolationError: Buffer output getitem_1 does not point to a buffer that exists.
  mutated target   : 'layers.0.self_attn.kv_cache.k_cache'
  buffer available : 'lifted_buf_layers_0_self_attn_kv_cache_k_cache'

Remapped through the same mapping, which is also recorded in meta so a later consumer
does not have to reconstruct the renaming rule.

3. The aliasing prediction ignores torch_executed_ops

_kv_write_will_alias decides whether a write becomes engine-level aliasing by looking at
the op, and never sees the ops the caller excluded from TensorRT. An excluded write is still
predicted to alias, its copy_ is dropped, and then the cross-check in compile() fails:

RuntimeError: lift_mutated_buffers classified these buffer writes as KV-cache
(engine-aliased) and dropped their copy_, but the compiled engine did not alias them
(absent from aliased_io): [... 16 buffers ...]. Their write-back would be silently
dropped.

An op that never reaches a converter cannot emit an IKVCacheUpdateLayer, so the prediction
now honors the exclusion list, matched with ConverterRegistry.qualified_name_or_str the
same way the partitioner matches it, so the two cannot disagree about the same op.

That guard is worth calling out: it turned a cache that would silently stop updating into a
clear error naming every affected buffer.

4. An excluded write should not be lifted at all

With the prediction corrected the export gets further, then fails inside ExecuTorch:

RuntimeError: Tried to erase Node getitem_145 but it still had 1 users
in the graph: {executorch_call_delegate_1: None}

Lifting the buffer turns the mutation into a delegate output. When the write runs on the
other backend, that output feeds the second delegate, and ExecuTorch cannot express a buffer
mutation consumed across a delegate boundary. If TensorRT is not converting the write, it
now leaves the buffer alone so the copy_ stands for whichever backend claims it.

Testing

The existing suite passes unchanged: tests/py/dynamo/lowering/test_buffer_lifting.py,
19 passed.

Those tests all use a cache owned by the top-level module (a name with no dots), which is
why none of them catch problem 1. Verified the fixes on a two-layer model that owns its
caches at layers.N.attn.k_cache:

lifted buffers: 2                        (0 before this change, the lookup failed)
name mapping recorded: 2
  layers.0.attn.k_cache -> lifted_buf_layers_0_attn_k_cache
  layers.1.attn.k_cache -> lifted_buf_layers_1_attn_k_cache
copy-back targets dangling: 0

with the write excluded from TensorRT: lifted 0   (correctly left alone)
without exclusion:                    lifted 2

End to end, with all four applied, a multi-method program carries both delegates and runs
correctly from C++:

prefill   delegates=['CudaBackend', 'TensorRTBackend']
decode    delegates=['CudaBackend', 'TensorRTBackend']
generated tokens vary per step, and logits match eager to 9.6e-05

Without them, excluding an op from TensorRT either drops a cache write or fails to lower,
so a model needing part of its graph on another backend cannot be exported.

Happy to split this into four commits if that reviews better, or to fold it into #4459
directly if the author prefers.