Krauncher analyzer

Runtime, cost and performance analysis of a GPU job, before running it. Use it to predict how long a training or inference job will take, find what holds its performance back, see whether the GPU is utilized or left waiting on the host, and pick the run parameters that make the code faster or cheaper. Numbers come from a corpus of measured runs — a runtime reasoned out of source is routinely wrong by several times. The code is analyzed, never executed: change a parameter, re-estimate, keep the cheaper variant — zero GPU-seconds. Returns, on a fixed reference card (RTX PRO 6000 WS): compute_sec / setup_sec / io_sec, min_vram_gb / min_disk_gb, cpu_only, confidence (0-1), analysis_method, findings (what the analyzer read from the code), plus knobs / spread / spread_reason / calibration_basis / iterations / iteration_basis: `knobs` is the shortlist worth re-estimating — change their VALUES ONLY, not the model, architecture, dataset or procedure. `value: null` means it is not a literal in this source (it arrives as an argument, a config entry or an env var), so name it in the code and estimate again. `same_work: false` (epochs, steps, sequence length) shrinks the job itself: report that as a change of task, never as a saving. `spread` is how far the same code scatters across real hosts: 1.5 means the slow end of the measured population runs about 1.5x the estimate. It is a measured factor, not doubt about the reading — confidence 1.0 with a large spread says the GPU is not what governs this job's time, the card waits on the host. The lever is GPU utilization: find what leaves the card idle (data loaded in the main process, per-item preprocessing, synchronous transfers, a batch too small to fill it). `spread_reason` names it. `calibration_basis` is "calibrated", "extrapolated" (a neighbour answered) or "uncalibrated" (read the seconds as an order of magnitude). `iterations` is the step count the whole estimate scales with, and `iteration_basis` is where it came fro…