Record both arms at the compact-WY factor row split (e6ee2d3)

[shinaoka]

What this moves

pins/tlinalg-rs.rev -> e6ee2d3304e042926c77cda7b81e58c871a98919 (the merge of tensor4all/tlinalg-rs#50, which consumes tensor4all/faer#6), both arms re-recorded from scratch, both cells full and current:

• result/zen5-cpu/tlinalg-kernels/e6ee2d3304e0-openblas.md (run 20261013T071911Z)
• result/zen5-cpu/tlinalg-kernels/e6ee2d3304e0-mkl.md (run 20261013T084748Z)

Why

With the block apply's reduction split (#4, #5), the tall c64 householder_factor cell was 16.05 ms against OpenBLAS's 12.50, and re-separating its phases showed the compact-WY factor build was still 2.7 ms with no scaling at all -- upgrade_householder_factor's flat branch reduces V_bot^H V_bot over every row below the basis' diagonal with an n x n output, one serial kernel per task (0.271 ms at 8T at m = 4096, n = 16). faer#6 splits its rows too. Its partials are n x n each and only the strict upper triangle is stored, so unlike the block apply's split it needs no depth-against-width gate and pays at every size (6.7x at 4096x16, 4.6x at 1024x16, 3.0x at 512x16).

The evidence in this record

Medians of after / before over each regime's cells, vendor rows of the two pairs as the floor:

rows	small	medium	large	tall
faer-1lane at 1T	1.005	1.004	1.001	0.999
faer-pool at 8T	1.003	1.001	0.993	0.857 (p10 0.815, p90 0.901)

Vendor floor: 1.000-1.002 median, p10-p90 0.983-1.023 over ~490 cells per row per arm.

Every blocked QR path builds this factor, so the change is wider than one cell -- at 8T (before -> after, vendors from the same runs):

case	before	after	OpenBLAS	MKL
householder_factor 4096x256 b1 c64	16.05	13.35	12.33 (1.08x)	11.10 (1.20x)
householder_factor 4096x256 b1 f64	5.63	4.90	10.74 (0.46x)	3.76 (1.30x)
qr 4096x256 b1 c64	42.76	36.87	25.74 (1.43x)	30.00 (1.23x)
rank_revealing_qr 4096x256 b1 c64	52.06	44.78	34.11 (1.31x)	-
svd_thin f64 4096x256 b1	34.38	26.89	37.11 (0.72x)	22.31 (1.21x)
householder_factor 512x512 b1 c64	4.49	4.17	6.53 (0.64x)	3.41 (1.22x)
householder_apply 256x256 b4 f64	1.71	1.43	-	-

Every 1T row is unchanged, and the families that build no compact-WY factor (lu_*, cholesky, eigh*, svd_values, triangular_solve) sit inside the floor.

Where the family that started this stands

householder_factor 4096x256 b1 was 10.2x behind OpenBLAS at 8T when this campaign first recorded it, 1.55x after the blocking, and reads 1.08x in c64 and 0.46x in f64 now. The tall c64 cells that still lose are qr (1.43x OpenBLAS, 1.23x MKL) and rank_revealing_qr, which call faer's own blocked QR rather than tlinalg's kernels; the worklog and the fork's PATCHSET.md carry the one part left inside tlinalg's path -- the panel, ~5 ms of that cell's 13.4, whose grain is a single reflector.

Checks

• scripts/validate_run.py on both manifests: ok.
• scripts/gen_index.py --check: current.