[Code scan] Fix implib vtable byte extraction offsets

[njzjz]

This issue was found by a Codex global scan of the repository at commit 19f9265.

The experimental implib-gen.py --vtables path appears to read and decode vtable/typeinfo data from the wrong byte offsets.

read_unrelocated_data() seeks to the start of the containing section, not to the symbol's offset inside that section:

deepmd-gnn/third_party/implib/implib-gen.py

Lines 288 to 297 in 19f9265

	for name, s in sorted(syms.items(), key=lambda s: s[1]["Value"]):
	# TODO: binary search (bisect)
	sec = [sec for sec in secs if is_symbol_in_section(s, sec)]
	if len(sec) != 1:
	error(
	f"failed to locate section for interval [{s['Value']:x}, {s['Value'] + s['Size']:x})"
	)
	sec = sec[0]
	f.seek(sec["Off"])
	data[name] = f.read(s["Size"])

collect_relocated_data() then iterates in pointer-sized byte offsets but multiplies the offset by ptr_size again when slicing:

deepmd-gnn/third_party/implib/implib-gen.py

Lines 311 to 314 in 19f9265

	for i in range(0, len(b), ptr_size):
	val = int.from_bytes(
	b[i * ptr_size : (i + 1) * ptr_size], byteorder="little"
	)

For symbols not at the beginning of a section, or for fields after the first pointer, this can generate corrupted vtable C initializers. The current deepmd-gnn dynamic-cudart path does not pass --vtables, so this is isolated to the vendored implib feature, but it is still tracked code.

Suggested fix: seek to sec["Off"] + (s["Value"] - sec["Address"]), slice with b[i : i + ptr_size], and add a small fixture that verifies a vtable symbol located away from section offset zero.