main: export BLACKSMITH_STICKYDISK_KEY for downstream build attribution

[piob-io]

Summary

docker_build_histories attribution is broken for v2 custom cache keys: the backend looks up the sticky disk entity by stickydisk_key = repo_name (the v1 default), so builds behind a custom cache-key get pinned to the old repo-named entity (observed on Hero-Apps-Dev/HeroNet, where all builds still attribute to the Hero-Apps-Dev/HeroNet entity while the builder actually runs on heronet/app).

This PR is the first link in the fix: after a successful sticky disk setup, the action exports the configured key so later steps can report it:

core.exportVariable("BLACKSMITH_STICKYDISK_KEY", core.getInput("cache-key"));

The variable is only exported when the Blacksmith builder setup succeeds (not on local-builder fallback), so a reported key always identifies a real Blacksmith sticky disk.

Companion PRs: build-push-action reads this variable and sends it as stickydisk_key in the build-start report; the web backend prefers it in the entity lookup, falling back to repo_name for v1 clients.

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.}

[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