Summary:
## Context

PyTorch PR pytorch/pytorch#179754 (fixing pytorch/pytorch#178042) added a dtype validation check to the `aten.embedding` meta registration in `torch/_meta_registrations.py`:

```python
torch._check(
    indices.dtype in (torch.long, torch.int32),
    lambda: (
        "Expected tensor for argument #1 'indices' to have one of the following "
        f"scalar types: Long, Int; but got {indices.dtype} instead"
    ),
)
```

This aligns the meta function with the C++ implementation (`checkScalarTypes` in `Embedding.cpp`), which already enforced integer indices. Previously, no meta registration existed for `aten.embedding`, so FakeTensor tracing during `torch.export`/`torch.compile` silently accepted float indices, and AOTAutograd's DCE could remove the dead node before the C++ check ever fired.

## Problem

`test_batched_export_with_backprop` in `test_static_attention.py` creates example token inputs using `torch.zeros()` without specifying a dtype:

```python
# Before (defaults to torch.float32)
torch.zeros(batch_size, input_len)
torch.zeros(1, input_len)
```

During `torch.export.export()`, these float32 tensors flow into `self.tok_embeddings(tokens)` (an `nn.Embedding` layer in `llama_transformer.py`), which dispatches to `aten.embedding`. The new meta function dtype check rejects float32 indices, causing the export to fail.

Note that the actual backprop loop already uses integer indices correctly via `torch.randint(config.vocab_size, (batch_size, input_len))` — only the export-tracing example inputs were wrong.

## Fix

Add explicit `dtype=torch.long` to both `torch.zeros` calls used as token example inputs:

```python
# After
torch.zeros(batch_size, input_len, dtype=torch.long)
torch.zeros(1, input_len, dtype=torch.long)
```

Differential Revision: D101547370