Fix mutated-buffer tagging after indirect mutation detection change

[metascroy]

PR #22172 updated tag_constant_data() to identify mutated buffers through the exported program’s graph signature. However, tag_mutated_buffer() retained the previous direct-user heuristic.

This left indirectly mutated buffers outside delegate partitions. For MLX KV-cache models, the cache became a delegate input while its updated value was also assigned an output slot, causing:

Slot for getitem already set to Output, trying to set to Input
Update tag_mutated_buffer() to use the same graph-signature-based detection as tag_constant_data() and add regression coverage for indirect buffer mutation.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/22296

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ You can merge normally! (1 Unrelated Failure), 1 Unclassified Failure

As of commit 4fe4109 with merge base 0447246 ():

UNCLASSIFIED FAILURE - DrCI could not classify the following job because the workflow did not run on the merge base. The failure may be pre-existing on trunk or introduced by this PR:

• MLX / test-mlx-llm (google/gemma-4-E2B-it, gemma4-e2b, false, 4w, macos-15-xlarge) / test-mlx-llm-gemma4-e2b-4w (gh) (this job did not run on the merge base, so DrCI cannot tell whether the failure is pre-existing)
  ##[error]error: RPC failed; curl 56 Recv failure: Connection reset by peer

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / test-qnn-testsuite-linux / test-backend-linux (qnn, models) / linux-job (gh) (trunk failure)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.