[BUG]: FFT sample launches `Batch` blocks that each process the full batch

Version

1.5.0

Version

13.3

Describe the bug.

In samples/FFT.py, cutile_fft() sets the kernel constant BS to the full batch size (BS = x.shape[0], line 274) and also launches grid = (BS, 1, 1) (line 315). Inside fft_kernel every block loads a (BS, N*2//D, D) tile at index (bid, 0, 0) — i.e. every block loads and transforms the entire batch, then writes it out. The result is numerically correct, but the work is O(Batch²) instead of O(Batch), and the kernel spills registers / shared memory at modest batch sizes.

Expected: one block per batch item (or per fixed-size minibatch), with the grid sized Batch // BS, so cost scales linearly with batch.

Measured on a DGX Spark, N=512, batch=64, factors=(8,8,8), twiddles precomputed: kernel time 2376 µs -> 12 µs (~200x) after fixing the grid/BS relationship.

Contributing Guidelines

• I agree to follow cuTile Python's contributing guidelines
• I have searched the open bugs and have found no duplicates for this bug report

Start in samples/FFT.py at cutile_fft() around the BS assignment on line 274 and grid launch on line 315, then read fft_kernel to trace how bid selects its tile. Run the FFT sample with the reported N=512 and batch=64 configuration, and verify that the output remains numerically correct while kernel work and timing scale linearly with the batch.