fix(test): make container and store tests platform-aware on Windows

[jahvon]

Unblocks the Windows check on #439. These failures are not from that PR — all four specs exist unchanged on main.

Summary

Four specs asserted Unix-only behavior and failed on Windows. They have been latent for a while: windows-ci only runs behind the test:windows label, and no PR had carried it since the code that introduced them. Labelling #439 ran them for the first time.

Spec	Why it failed on Windows
expands and mounts workspace-relative and absolute volumes	/opt/data is not absolute under filepath.IsAbs
expands volume host paths [absolute]	same
writeEnvFile writes sorted 0600 entries	mode read back as 0666
BoltDataStore — entire suite	ERROR_INVALID_NAME in BeforeEach

Volume paths. expandVolumeHost gates on filepath.IsAbs, which rejects /opt/data on Windows — there an absolute path needs a drive letter. Two specs hardcoded it as the host side of a volume. They now build the host path for the platform. The container side stays Unix, since container paths are always Linux paths, and ExecContainerVolume.Parts already handles the drive-letter colon.

File mode. Go maps Unix permission bits onto ACLs on Windows, so 0600 is not expressible and reads back as 0666. The assertion is skipped there and still enforced everywhere it means something. The content assertion is unchanged.

Store suite. This one took out every spec in pkg/store, not just the offending one. The database filename was derived from the spec name:

path := filepath.Join(GinkgoT().TempDir(), fmt.Sprintf("test_%s.db", GinkgoT().Name()))

One spec is named ... (running -> terminal), and > is not a legal Windows filename character — so BeforeEach failed with ERROR_INVALID_NAME (0x7b). TempDir is already unique per spec, so the suffix bought nothing and is dropped.

Scope

Test-only. The production paths were already Windows-capable — Parts handles drive letters, and container paths are correctly validated with Unix semantics. This fixes assertions, not behavior.

Testing

Verified on real Windows runners via workflow_dispatch rather than inferred from GOOS reasoning:

• Before: 3 failures (2 volume specs + writeEnvFile).
• After the first fix: those cleared, exposing the store suite failure underneath — which had been masked by the earlier ones.
• After both: all six Windows jobs green — unit, E2E, build, binary smoke, native script execution, validation.

Unix behavior is unchanged: go test -tags=unit ./internal/runner/exec/ ./internal/services/run/ ./pkg/store/ passes locally, and the affected specs still assert the same things on Unix.

🤖 Generated with Claude Code

https://claude.ai/code/session_01R328pa3FUUfga4gYah1iQi

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!