ci: install baton via get-baton action

[luisina-santos]

Summary

• Swap the "Install baton" CI step from downloading conductorone/baton's latest GitHub release to using ConductorOne/github-workflows/actions/get-baton@v4, which builds the baton binary from conductorone/baton-sdk instead.
• Update the two baton grants / baton entitlements call sites from ./baton to baton (the action installs to /usr/local/bin).

Why

PR #51's CI run (and likely any CI run right now) fails the "Test sync resolves DNs for every resource type" step with Error: c1z: invalid file. The standalone conductorone/baton CLI's latest release (v0.4.5) is still built against baton-sdk v0.8.24, while baton-ipa depends on baton-sdk v0.25.0. The connector's sync now writes c1z files using the newer pebble-store-backed format, which that old CLI can't parse — so every baton grants/baton entitlements call in the assertion step errors out and is misreported as a missing grant.

get-baton installs a baton binary built from conductorone/baton-sdk releases, so it stays in step with whatever SDK version the connector uses.

Test plan

• CI run on this PR passes the "Test sync resolves DNs for every resource type" step

[github-actions]

Connector PR Review: ci: install baton via get-baton action

Blocking Issues: 0 | Suggestions: 1 | Threads Resolved: 0
Criteria: Criteria status: loaded .claude/skills/ci-review.md from trusted base e3903123d780.
Review mode: incremental since b15aec80
View review run

Review Summary

The new commit only deletes the explanatory comment above the Install baton step in .github/workflows/ci.yaml; no Go, config, or dependency files changed anywhere in this PR. The full PR diff was scanned for security and correctness issues and none were found: the change swaps a hand-rolled gh release download of conductorone/baton for the ConductorOne/github-workflows/actions/get-baton@v4 action and drops the now-unneeded GH_TOKEN, which is CI-only and touches no connector code paths. The prior finding about scripts/get-baton.sh still pulling the incompatible conductorone/baton CLI (referenced from scripts/local-ldap/check.sh:14) is not addressed by this commit and remains open.

Security Issues

None found.

Correctness Issues

None found.

Suggestions

• .github/workflows/ci.yaml:130-131 - removing the comment drops the non-obvious rationale for using the get-baton action instead of the conductorone/baton release, making a regression back to the incompatible CLI easier.

Prompt for AI agents

Verify each finding against the current code and only fix it if needed.

## Suggestions

In `.github/workflows/ci.yaml`:
- Around line 130-131: The commit removed the comment explaining why the `Install baton`
  step uses `ConductorOne/github-workflows/actions/get-baton@v4` rather than downloading a
  `conductorone/baton` release. That rationale is non-obvious: the standalone
  `conductorone/baton` CLI trails baton-sdk releases and fails with "c1z: invalid file"
  when reading a c1z written by the newer, pebble-store-backed SDK this connector uses.
  Restore a one-line comment above the step capturing that constraint, so a future change
  does not revert to the incompatible CLI (which `scripts/get-baton.sh` still downloads).

[github-actions]

No blocking issues found.

[github-actions]

🟡 Suggestion: This commit drops the comment explaining why the get-baton action replaced the conductorone/baton release download (that CLI trails baton-sdk and fails with c1z: invalid file on this connector's output). Without it, the next person hitting a baton install problem in CI has no signal against swapping back to scripts/get-baton.sh, which still downloads that same incompatible release. Consider keeping a one-line version of the rationale here.

[github-actions]

No blocking issues found.