docs(repro): use supported indirect address-table ABI

[learning-chip]

Summary

• replace the unsupported nested-pointer and pto.load_ptr sketches with the supported GM i64 address-table ABI
• add a runnable PTODSL regression that emits pto.ld_dev, pto.castptr, and GM-to-UB DMA from a dynamically selected table entry
• keep the full recurrence benchmark as the remaining performance work

Validation

• python -m py_compile docs/repro/indirect_buffer_abi/fixtures/pointer_table_abi.py
• git diff --check

Relates to #1219

[mouliangyu]

We reviewed the pointer-table requirement and propose keeping nested PTO pointer types unsupported. Please represent a GM pointer table explicitly as pto.ptr(pto.i64, "gm") instead of pto.ptr(pto.ptr(T, "gm"), "gm").

The supported pattern is:

def kernel(
    table: pto.ptr(pto.i64, "gm"),
    dst: pto.ptr(pto.f32, "gm"),
):
    addr = pto.load_scalar(table, i, bypass_l1=True)
    src = pto.castptr(addr, pto.ptr(pto.f32, "gm"))
    # Use src with load_scalar, mte_gm_ub, etc.

This models each table entry according to its actual ABI representation: a 64-bit device address. load_scalar returns the address as i64, and castptr makes the pointee type and address space explicit at the use site. The offset of load_scalar is an element offset, so entry i addresses the expected i * 8 byte slot.

We verified this pattern on the latest main (887357eb):

• PTODSL successfully emits pto.ld_dev ... -> i64 followed by pto.castptr ... -> !pto.ptr<f32, gm>.
• PTOAS A5/VPTO backend compilation completes successfully and produces the device object.
• Dynamic table indices are accepted.

Therefore we do not plan to add pto.load_ptr or support ptr<ptr<T>>. The reproducer can use the explicit ptr<i64> address-table ABI and avoid the stack/unstack workaround.