Add macOS and Windows runners to the CI test matrix

[sundaram2021]

Is your feature request related to a problem? Please describe.

Our CI only exercises the CLI on Linux — .github/workflows/test.yml runs on ubuntu-latest only — even though we ship prebuilt binaries for macOS and Windows via GoReleaser (darwin_amd64/arm64, windows_amd64/arm64). That leaves two blind spots:

1. No platform coverage. The CLI leans on OS-specific backends — zalando/go-keyring uses wincred on Windows, the security binary on macOS, and D-Bus on Linux (all three are in go.mod) — plus platform-specific paths and terminal handling. A regression that only shows up on macOS or Windows won't surface until a user hits it after a release. CLI is broken on windows git bash #80 ("CLI is broken on Windows Git Bash") is a prior example of exactly that kind of platform-specific breakage slipping through.

2. The tests don't actually run. The job is named "Go Test & Vet", but it only runs go vet + a build smoke test — go test ./... is never invoked, on any OS. So even the Linux job isn't executing the suite.

Describe the solution you'd like

Turn the single-OS job in test.yml into a matrix and make it actually test:

• Add a matrix over ubuntu-latest, macos-latest, windows-latest, with fail-fast: false so one platform's failure doesn't cancel the others.
• Add a go test ./... step.
• Make the existing steps cross-platform — the current build step is bash-only and breaks on Windows:
  • CGO_ENABLED=0 <cmd> is a bash-ism; Windows runners default to PowerShell, so CGO_ENABLED should move to a job-level env: block.
  • -o /dev/null doesn't exist on Windows; go build ./... compiles every package (main included), discards the output, and works on all three OSes.

Since test.yml is a reusable workflow (on: workflow_call) called by both main.yml (PRs + pushes to main) and release.yml (tags), this one change covers both PR CI and the release gate.

Proposed test.yml job

jobs:
  test:
    name: Go Test & Vet (${{ matrix.os }})
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
    env:
      CGO_ENABLED: "0"
    steps:
      - uses: actions/checkout@v6
      - uses: actions/setup-go@v6
        with:
          go-version: "1.24"
          cache-dependency-path: src/go.sum
      - name: Download dependencies
        working-directory: src
        run: go mod download
      - name: Vet
        working-directory: src
        run: go vet ./...
      - name: Test
        working-directory: src
        run: go test ./...
      - name: Build (smoke test)
        working-directory: src
        run: go build ./...

Describe alternatives you've considered

• Just adding OSes to runs-on without fixing the build step — the /dev/null + inline-env command fails on Windows PowerShell, so the matrix would go red on Windows for the wrong reason.
• Keeping it to vet + build across OSes (no go test) — catches compile/vet breaks but not behavioral regressions, which is the main point of multi-OS testing.

Additional context

I validated the change locally with Go 1.24:

• go test ./... passes — 30 tests across cmd, pkg/ai, pkg/config, pkg/util.
• GOOS=windows go vet ./... and GOOS=windows go build ./... are both clean, confirming the tests + source compile for Windows.
• The existing tests look cross-platform-safe (they use t.TempDir(), filepath.Join, os.Pipe, t.Setenv — no hardcoded POSIX paths or shelling out to Unix-only tools).

I've already prototyped this and am happy to open a PR if the maintainers are open to it.