ci(windows): add non-blocking baseline lane

[liugddx]

Summary

• add an explicitly non-blocking windows-latest baseline lane
• capture install, build, skip inventory, script, CLI/Electron smoke, storage, and residual-process evidence
• preserve each command's native exit status while allowing the baseline job to complete and upload logs
• make the Phase 0 inventory check insensitive to Windows checkout line endings

Part of #2142 (Phase 1: continuous Windows correctness).

Current Windows baseline

The validated run reports:

• install, build, inventory, script tests, CLI/Electron smoke, and residual-process audit: success
• storage: failure, intentionally recorded in the summary and artifact
• storage totals: 654 tests, 518 pass, 101 fail, 35 skipped
• residual repository Node/Electron processes: none

The job remains non-blocking while the Phase 1 backlog is reduced. A green job conclusion does not hide step outcomes: the job summary records ${{ steps.<id>.outcome }} and complete logs are retained in the windows-baseline artifact.

Validation

• node --test scripts/windows-test-inventory.test.mjs scripts/windows-baseline-workflow.test.mjs
• npm run windows:inventory
• npm run test:scripts
• fork CI: https://github.com/liugddx/maka-agent/actions/runs/30925437821
• Windows runner: https://github.com/liugddx/maka-agent/actions/runs/30925435800

[Astro-Han]

Thanks for adding a real Windows baseline while keeping it explicitly non-blocking. I checked the live run: native exit outcomes are preserved, the storage failure is visible in the summary, logs are uploaded, and the workflow remains fork-safe with read-only permissions.

I found one gap in the residual-process evidence. The audit only treats a process as repository-owned when its command line contains GITHUB_WORKSPACE. The storage runner and its npm/Node children are commonly started with relative commands plus a repository cwd; Windows exposes the command line but not that cwd in CommandLine, so a leaked test process can be missed and reported as no residual process.

Could we identify run-owned processes through the process tree, tracked PIDs, or another signal that does not depend on the workspace path appearing in the command line, and verify the tree after cleanup? The rest of the baseline workflow looks sound.

[liugddx]

Thanks, this was a real gap. Fixed in 3948d5ce.

The workflow now snapshots existing Node/Electron process identities as (PID, CreationDate) before any repository commands run. The final audit treats every new Node/Electron identity as job-created, so it no longer depends on GITHUB_WORKSPACE appearing in CommandLine and catches children launched through relative commands plus cwd.

For any residual root, the audit expands the CIM snapshot through ParentProcessId, records the complete descendant tree, runs taskkill /T /F, and verifies every captured tree identity is gone after cleanup. The baseline, residual roots, full tree, cleanup log, and post-cleanup result are retained in the artifact.

Validated on the updated upstream PR run: the audit reported No residual job-created Node or Electron processes, the residual-process outcome was success, and all required checks including the new Windows package check passed.

[Astro-Han]

Thanks for addressing the residual-process ownership gap. I rechecked the updated workflow and the successful Windows run; this is good to merge.

One low-priority follow-up: ConvertFrom-Json may deserialize the ISO CreationDate into a DateTime, while the current-process side explicitly formats it with ToString('o'). A non-empty baseline could therefore produce different identity strings. This is not blocking for the current non-blocking hosted-runner baseline, but it would be worth normalizing both sides through the same identity formatter and covering a non-empty baseline fixture in a follow-up.