v1.4.3

Auto-Calibration clarity + crash patch. A field-report sweep (#74 / #76 plus a direct e-mail report on 88D2) showed the Auto-Calibration Wizard was working as designed on several boards but communicating badly — a deliberately-skipped 100% step read as "stuck at 70%", and a benign top-step RPM match raised a scary "PLATEAU DETECTED — add this board to the freeze list" alarm on healthy hardware. This release fixes the messaging, relabels two misidentified info fields, makes the wizard teardown release the fan rate registers (not just the level registers), and hardens the CLI exit path against an "invalid handle" crash. No new features; no hardware-control behaviour changes beyond the teardown completion.

Fixed

• CLI crash Exception: Nieprawidłowe dojście / "invalid handle" after a console command (issue #76, reported by @simoliguori). Cli.RestorePrompt() — the cosmetic "make the command prompt reappear" hack run on the first-instance CLI path (and from App.Exit()) — read Console.CursorTop, which calls GetConsoleScreenBufferInfo under the hood and throws a WinIOError when standard output is not a real console screen buffer (output redirected to a file/pipe, or the process launched without an inheritable console). That exception escaped to Main() and surfaced as the crash dialog in the screenshot. RestorePrompt() now wraps its console access in a best-effort try/catch (consistent with the codebase's graceful-degradation style) — when there is no usable console buffer there is simply nothing to restore, and the work the command already did is unaffected.
• Auto-Calibration report read as "stuck at 70%" on max-fan-freeze boards (issue #74, reported by @MartinSalg818, 8BAD). On a board in FanArray.HasMaxFanFreeze, the wizard intentionally filters the 100% step out of its profile (commanding 100% locks the EC until reboot on these models — the safety behaviour added in v1.4.1). But the report just showed Profile: 0% → 30% → 70% with no explanation, so a truncated sweep looked like a malfunction. The wizard now records that the omission was deliberate (CalibrationOutcome.MaxStepSkippedForFreeze) and the report carries a clear "100 % step intentionally skipped — <ProductId> is on the known freeze list, this is expected and not a malfunction" note above the Device block.
• False "PLATEAU DETECTED at 100 %" alarm on healthy boards (direct e-mail report, 88D2 HP Omen 15). The wizard's plateau detector fired on the final step too, where it could not prevent anything (the 100% command had already run) and where "top step ≈ previous step" is the normal case on boards whose manual fan-level scale already reaches the physical ceiling. The result was a prominent "the board is at its physical fan ceiling — please add 88D2 to FanArray.HasMaxFanFreeze" call-out on a board that is not freeze-prone (the owner confirmed the fans audibly spin faster at manual max). Plateau detection now only raises that alarm — and the safety-list recommendation — when a higher step was actually skipped (an actionable, freeze-preventing plateau). A no-gain reading on the last step is recorded as a neutral, informational note that explicitly does not recommend a safety-list addition, and points out the one case worth a closer look (a register mirroring the commanded level rather than a true tachometer).
• Auto-Calibration report labelled the BIOS born-date as "BIOS Build Date" (issue #74). The value comes from GetBornDate() — the factory manufacture/"born" date — not the firmware build or version. The mislabel led the reporter to flag 20240904 as wrong against their actual BIOS build (20260421). The report now reads BIOS Born Date with an inline "(factory manufacture date — not the firmware build/version)" clarification.
• Auto-Calibration Wizard could leave the fans pinned at the last commanded step after running (issue #74, reported by @MartinSalg818, 8BAD — follow-up to the v1.4.2 #65 fix). ApplyLevel() drives both the fan level registers and the per-fan rate registers on every sub-100% step, but the v1.4.2 teardown only released the level registers (writing 0xFF, 0xFF). On boards whose EC keeps driving the fans from the rate register after manual mode is released, the stale rate write left the fans stuck at the last step ("locks at 70%"). The wizard now captures each fan's rate register before the sweep and restores it in the teardown finally{}, symmetric with the existing level restore. Best-effort: a genuinely frozen EC ignores the restore writes and still requires a reboot, but a board that merely had a sticky rate register now recovers cleanly.
• GUI system-info line showed a bare CPU PL4 wattage that read as the power-adapter rating (issue #74). The main window printed GetDefaultCpuPowerLimit4() (the CPU Power Limit 4, in watts) as an unlabelled "200W" immediately before the AC-adapter status, so the reporter read it as a "200 W power brick" and flagged it against their real 330 W HP adapter. The wattage is now prefixed with a CPU PL4 label so it is no longer mistaken for the charger rating. (OmenMon does not read or display the AC-adapter's wattage — HP's smart-adapter BIOS call only returns a sufficient/insufficient status, not a rating.)