feat(alertmanager): route paperclip_data_volume to an owner + sync docker adapter-pin test (BLO-10699)

[kkroo]

Issue (inline description — BLO-10699 follow-up)

What happened?
The byte-usage watermark alerts on the shared paperclip-data CephFS PVC
(PaperclipDataVolumeNearlyFull / PaperclipDataVolumeCritical, shipped in
onprem-k8s#804) carry the label class: paperclip_data_volume. The alertmanager
plugin's DEFAULT_OWNER_MAP only routes class: paperclip_claude_k8s, so this
new alert resolves to source: "no-match" and the auto-created Paperclip issue
is unassigned — nobody is paged for a filling shared HOME that walls the
whole agent fleet at workspace materialization (the EDQUOT incident itself).

Expected behavior
The data-volume alert class routes to a durable default owner, like every other
bundled alert class.

Steps to reproduce
Fire an Alertmanager alert with labels.class = "paperclip_data_volume" and no
paperclip_assignee_email override → today the resulting issue has no assignee.

Paperclip version or commit
master @ c772d35 (current tip).

Thinking Path

The resolver (owner-resolver.ts) is pure and order-driven: a direct override
label wins first, then the merged ownerMap is matched by label key, then an
annotation override, else no-match. The data-volume alert carries no override
labels, so the only place to give it an owner without operator config is the
bundled DEFAULT_OWNER_MAP — exactly where paperclip_claude_k8s already lives,
keyed on the same class label. So the minimal, consistent fix is one map entry
mirroring the existing class route, rather than touching resolution logic. I kept
it in DEFAULT_OWNER_MAP (not a hardcoded resolver branch) because mergeOwnerMap
in worker.ts layers operator instance config on top of the defaults, so this stays
an overridable default, not a lock, and is covered by the existing merge tests.

What Changed

• constants.ts: add paperclip_data_volume: "support@blockcast.net" under DEFAULT_OWNER_MAP.class, mirroring the existing paperclip_claude_k8s entry, with a comment tying it to the onprem-k8s alert.
• owner-resolver.test.ts: add a test asserting the new class resolves to support@blockcast.net via source: "owner-map" (mirrors the claude_k8s default-route test).
• server/src/__tests__/docker-opencode-runtime-pin.test.ts: sync the pinned adapter SHAs to chore(docker): bump CLAUDE_K8S_REF + OPENCODE_K8S_REF — Chrome BrowserMetrics + --resume guard (BLO-10699) #447's bump (CLAUDE_K8S_REF af5df84→f79ab9a, OPENCODE_K8S_REF 4b195304→cac7d0b). chore(docker): bump CLAUDE_K8S_REF + OPENCODE_K8S_REF — Chrome BrowserMetrics + --resume guard (BLO-10699) #447 bumped the Dockerfile refs but missed this guard test, leaving master red (Release verify_canary) and breaking every PR off master — this PR carries the test-side fix that should have ridden with chore(docker): bump CLAUDE_K8S_REF + OPENCODE_K8S_REF — Chrome BrowserMetrics + --resume guard (BLO-10699) #447. All comment-string assertions in the guard still hold.

Verification

• pnpm exec vitest run in paperclip-plugin-alertmanager: 72/72 pass (owner-resolver 24, worker 30, issue-mapping 18).
• Traced resolveOwnerEmail → the class label hits the merged map → email branch → owner-map. mergeOwnerMap is key-additive, so operator overrides remain intact (covered by existing worker tests).

Risks

• Minimal. Additive map key; no behavior change for any other alert class. Worst case the route is "wrong owner" (support@), trivially overridable via instance ownerMap config without a code change. No schema/secret/infra change.

Model Used

Claude Opus 4.8 (1M context).

• I searched for existing/duplicate work before opening this PR (BLO-10699 follow-up; this is the routing-key item flagged in onprem-k8s#804's body).

🤖 Generated with Claude Code

[allyblockcast]

Hey @kkroo! Before this PR can be reviewed, a few things need attention:

Missing or incomplete:

• No linked issue or inline issue description found — either tag an existing issue with Fixes #NNN / Closes #NNN / Refs #NNN, or describe the underlying issue inline in the PR body following one of our issue templates (https://github.com/paperclipai/paperclip/tree/master/.github/ISSUE_TEMPLATE). See CONTRIBUTING.md → "Link Issues or Describe Them In-PR".

Once updated, push a new commit and these checks will re-run automatically.

— commitperclip

[allyblockcast]

Hey @kkroo! Before this PR can be reviewed, a few things need attention:

Missing or incomplete:

• Thinking Path needs more detail (2 sentences — aim for 3+)

Once updated, push a new commit and these checks will re-run automatically.

— commitperclip