test(data): Windows chronicle PTY and dbwatch ResetBaseline untested

[jongio]

Summary

The Windows-specific PTY chronicle writer (internal/data/chronicle_windows.go) and the database watcher's ResetBaseline function (internal/data/dbwatch.go:59) both have 0% test coverage. These are data-layer functions responsible for recording session output and detecting database changes.

Affected Functions

Function	File	Coverage
ptyHandle.Write	chronicle_windows.go:34	0.0%
ptyHandle.Read	chronicle_windows.go:33	0.0%
ptyHandle.Close	chronicle_windows.go:35	0.0%
startPTY	chronicle_windows.go:44	0.0%
findCopilotBinary	chronicle_windows.go:54	0.0%
ResetBaseline	dbwatch.go:59	0.0%

Details

chronicle_windows.go implements the ConPTY-based pseudo-terminal used for reindexing Copilot CLI sessions on Windows. The ptyHandle type wraps ConPTY with idempotent close semantics (via sync.Once) to prevent access-violation panics from double-closing HPCON handles. None of this safety logic is tested.

ResetBaseline in dbwatch.go resets the file-system watcher's baseline so subsequent HasChanged calls detect new modifications. This is used after the TUI processes a batch of database changes. If ResetBaseline fails silently, the TUI could either miss updates or spin in a hot loop re-processing old changes.

Recommendation

• Test ptyHandle.Close idempotency by calling Close twice and verifying no panic and consistent error return
• Test findCopilotBinary with controlled PATH and environment variables (set APPDATA to a temp dir with a fake copilot.exe)
• Test ResetBaseline by creating a temp DB file, calling HasChanged (should be false), modifying the file, calling HasChanged (true), then ResetBaseline + HasChanged (false again)
• For startPTY, consider a build-tagged integration test that verifies ConPTY creation succeeds when copilot is available

[jongio]

Consolidated into a single tracking issue.