fix(oxide-tilebc): write the fragment's symbolic shape as the 13.5 assembler reads it

[nihalpasham]

What this adds

A .tilelib written by cargo oxide tilelib now loads on the CUDA 13.5 assembler.

before: 13.5 tileiras rejects the implementation descriptor: "concrete shape cache rank (1) does not match symbolic shape rank (0)"
after:  the descriptor parses, and a Tile C++ kernel calls the three exports through the library

What we fixed

• The 13.5 assembler keeps a full-rank symbolic shape on preview$fragment, one integer expression per dimension. The compiler trunk switched on 2026-09-08 to holding only the dynamic dimensions, and the writer produced that trunk form for every version.
• The fragment type now encodes per version: full rank below 13.6, dynamic-only from 13.6 on. Nothing else in the descriptors changes.

Implementation

• oxide-tilebc's type table carries the bytecode version, and the fragment arm branches on it.
• The 13.5 golden in the writer tests now holds a one-element symbolic tuple.

Verification

Checked at 514be3a18:

• ✅ oxide-tilebc 15 unit tests, clippy with warnings as errors, rustdoc.
• ✅ CUDA 13.5.40 release toolkit, RTX 5090: cargo oxide tilelib tilelib_relu --arch sm_120 builds the library, its disassembler reads both descriptors, and cpp/tile_caller.cu passes 3 of 3 through it.
• ✅ The 13.6 development build still reads the dynamic-only form: the same library built at 13.6 passes 3 of 3 there too.

Caveats

• The version switch keys on 13.6 because that is where the trunk form first ships; if a 13.5 update moves to the trunk form, the boundary moves with it.