[Feature]: revisit the host-side embedding pad now that padded compiled collectives are exact

[yannicks1]

Feature description

test_compiled_all_reduce_padded_is_exact was xfail(strict=True) and started passing with the
torch-spyre bump to 9f975a3 (#950): F.pad + all_reduce + index_select inside a compiled
graph is now bit-exact.

Check whether the workaround written around that constraint can be removed or simplified, and
whether that changes performance.

Motivation and context

_SpyreModelWrapper.embed_input_ids (spyre_inference/v1/worker/spyre_model_runner.py) pads
input_ids on CPU and trims the embeddings afterwards with select_rows. Its comment gives two
reasons for the pad:

1. some num_tokens * hidden collective schedules fail to build, and
2. padding inside a compiled collective corrupted output.

Only the second is fixed. That comment still states the second reason as current and is now
inaccurate.

Proposed solution

• Correct the comment.
• Check whether the pad can move inside the compiled region instead of being done host-side, which
  would drop the select_rows trim and reduce the embedding gather to num_tokens rows.
  _shape_bucketer is used elsewhere in spyre_model_runner.py, so bucketing would have to move
  rather than be deleted.
• The remaining blocker is collective-schedule buildability, not correctness.
• Benchmark prefill and decode before and after; do not land a simplification that regresses.
• Keep the probe as a positive assertion.

Checklist

• I have searched for similar feature requests