Make Windows batch entrypoints location-relative

[CoreyRDean]

Non-technical summary

This fixes the Windows command entrypoints so the build, test, and publish scripts work when they are launched from outside the repository root.

This matters now because the repo has already moved its hooks and Unix scripts toward location-relative behavior, but the main Windows batch entrypoints still depended on the caller's current directory. That made routine contributor workflows fragile for no product benefit.

After this change, the Windows batch workflow is more predictable: compile.bat, test.bat, and publish.bat now anchor themselves to the repo checkout instead of the shell location they were launched from.

Technical summary

• Updated compile.bat to derive ROOTDIR from %~dp0, switch drives with cd /d, and call the scripts/ helpers via absolute repo-root paths.
• Updated test.bat to derive ROOTDIR from %~dp0 and use cd /d for the test loop and repo-root return path.
• Updated publish.bat to call compile.bat through an absolute repo-root path and use cd /d when returning to the checkout root.
• Verified the live tree with ./test.sh on macOS after the change; the existing macOS compile-only test flow still passes.
• Windows cmd.exe execution was not available on this host, so Windows proof for the batch behavior is static review of the changed control flow rather than local runtime execution.
• No breaking API or product-surface changes.

Additional notes

Trade-off: I kept the scope strictly to path resolution and drive-safe directory changes instead of broadening into batch-script cleanup.

Deferred follow-up: the helper batch scripts under scripts/ could be given the same caller-independent treatment in a separate pass if we want every Windows helper to follow the same contract.

Remaining gap: this closes the top-level entrypoint fragility, but hosted or native Windows execution is still the stronger proof surface for the batch behavior itself.