QR `refactor!` rebuilds the bordered matrix every call (~114 KB) instead of updating values in place — fix the advertised hot path

WHAT: The csr_refactor! kernel is allocation-free, but the refactor! wrapper (src/qr.jl:151-160) rebuilds the entire bordered matrix on every call. Measured breakdown (n=200, r=3): _augmented_matrix rebuild of [S Usp; Vsp negI] = 96,072 B, CSC→CSR conversion = 18,272 B, kernel = 0 B, total = 114,200 B/call. The refactor!(F, A) form measures ~320 KB/call in the infra audit. WHY IT MATTERS: This is the Newton/time-stepping hot path the package advertises as its throughput story; the docstring (src/qr.jl:147-149) already concedes it is 'not yet fully zero-allocation', and the README (line 82) overstates allocation-freeness for the refactor!(F, A) form a Newton loop naturally uses. FIX: Mirror the LU augmented path (src/augmented.jl:134-141): build the bordered CSC/CSR once at construction and store it; on refactor! overwrite only the nonzero value slices from the new S/U/V (the negI block and selector-U ones are constant; only S and V values change since the pattern is fixed for given (n,r) and S pattern), then call csr_refactor! on the same CSR buffer. Requires a value-only writer into the stored CSR. As part of the same change, qualify README line 82 to say allocation-freeness applies to the cheap refactor!(F, nzval) form, not refactor!(F, A). EFFORT: M.

Priority: high. Filed from an automated next-steps audit of the QR/lstsq work (see PR #6).

Start with the refactor! wrapper in src/qr.jl:147-160 and compare the stored augmented path in src/augmented.jl:134-141. Keep the bordered CSC/CSR buffers across calls, update the changing value slices, and qualify README line 82 for the nzval form. Done means the stated n=200, r=3 hot-path allocation breakdown no longer includes rebuilding or conversion.