Discover the agent address from BLACKSMITH_AGENT_ADDR

[piob-io]

Discovers the Blacksmith agent (git-mirror gRPC and internal metrics endpoints) through the BLACKSMITH_AGENT_ADDR env var the agent advertises on every platform (FastActions/fa#4816); the action contains no hardcoded agent IPs, and agent problems never fail the job:

• shouldUseBlacksmithCache() requires BLACKSMITH_AGENT_ADDR in addition to BLACKSMITH_VM_ID, so runners without agent services use upstream actions/checkout behavior with a single info line and zero agent dials.
• setupCache() RPCs (up, getStickyDisk) are bounded by a 45s AbortController.
• Any agent error (Unimplemented on platforms without the service, refused or timed-out dials, anything else) warns and falls back to a standard checkout.

if (!getAgentAddr()) {
  core.info('[blacksmith] BLACKSMITH_AGENT_ADDR is not set; ... falling back to actions/checkout behavior')
  return false
}

Requires the agent change (FastActions/fa#4816) to be rolled out fleet-wide before this is released.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled. (Staging)}

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 0810c59. Configure here.}

[taha-au]

this feels excessively large, but useblacksmith/checkout is the legacy approach so not strongly opinionated

[piob-io]

We discussed this and decided to keep 45s. Context: this deadline covers more than the dial; the same AbortController bounds up() plus the getStickyDisk RPC, and agent-side that RPC synchronously does the Ceph expose (bounded at 60s in the agent) and the rbd-nbd map (another 60s), so a legitimately slow mount can run tens of seconds under Ceph load. 45s also matches the long-standing stickyDiskTimeoutMs=45000 in the stickydisk, setup-docker-builder, and setup-bazel actions, so all actions hitting this RPC share one number. Before this PR checkout had no deadline at all here (a wedged agent stalled checkout until the step timeout), so this is a strict improvement either way. On timeout the action falls back to a plain clone, so the worst case is one cache-less checkout.

[piob-io]

This actually matches the timeout for other sticky disk actions - the 45s includes exposing and mounting the sticky disk, not just reachability. I considered splitting this into two deadlines, but I don't expect dialing to be slow.