reporter: report the actual sticky disk key for build attribution

[piob-io]

Summary

docker_build_histories attribution is broken for setup-docker-builder v2 custom cache keys: the backend resolves the sticky disk entity by stickydisk_key = repo_name, so builds behind a custom cache-key get attributed to the stale repo-named entity (observed on Hero-Apps-Dev/HeroNet after their key split).

reporter.ts now includes the actual builder key in both the build-start payload and failure reports:

stickydisk_key: process.env.BLACKSMITH_STICKYDISK_KEY || process.env.GITHUB_REPO_NAME || ''

BLACKSMITH_STICKYDISK_KEY is exported by setup-docker-builder v2 after a successful sticky disk setup (useblacksmith/setup-docker-builder#127); v1 jobs don't set it, so the value falls back to the repo name — matching current behavior. The web backend companion PR prefers stickydisk_key in the entity lookup with the same repo_name fallback.

dist/ regenerated via npm run build.

Link to Devin session: https://app.devin.ai/sessions/6ee33a7c3e5848e9a39d85439b161082
Requested by: @piob-io

---

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

---

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

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

Superseded: we're avoiding action changes. Attribution is now fixed platform-side via storage-agent expose events (useblacksmith/storage-agent#605) + vm_id lookup in the backend (useblacksmith/web#10682).