ci: add self-hosted Woodpecker validation lane

[dporkka]

Summary

Adds an owned Woodpecker CI lane for Dev Plane on the existing bootstrap-ci pool. This is a fallback execution surface for the current personal-account GitHub-hosted runner dispatch failure; it does not replace or weaken .github/workflows/ci.yml.

Parity with GitHub CI

• Node 24
• Go 1.26.8
• golangci-lint v2.13.2
• NATS 2.10 JetStream enabled locally
• same CI environment defaults
• Go lint/vet
• web lint + typecheck
• SDK typecheck
• Go + SDK tests
• web tests
• full build
• git diff --check

Exact-head binding

The first executable command resolves git rev-parse HEAD and requires it to equal Woodpecker's runtime CI_COMMIT_SHA. A mismatched checkout fails before toolchain installation or verification, so a green pipeline is evidence for the exact forge-selected revision rather than merely the branch name.

Safety boundary

The checked-in Make/npm commands remain authoritative. Woodpecker only supplies compute. Evidence is valid only for the exact revision Woodpecker executed. Once PR #129's dev-plane verify CLI lands, this bootstrap lane can become a thin adapter around that canonical verifier rather than duplicating command sequencing.

Activation dependency

The repository must be activated in the existing Woodpecker instance so it can install the GitHub webhook. This PR cannot perform that account-level activation itself. Once activated, retrigger this PR (or run the workflow manually) and keep this PR draft until ci passes on this exact head.

Current candidate

Branch is one commit ahead and zero behind main d3dcdaae48d2a268e78d71b79b9433913ae59d91.

Exact candidate head: 1b2b2752af17e5fc3732efd9bc27ce5cc1d7d220.

GitHub-hosted Actions on this personal-account repository reproduces the previously diagnosed pre-run failure, so it is not usable as product-test evidence. This PR intentionally leaves GitHub Actions unchanged and remains draft until Woodpecker is activated and executes this SHA.

[dporkka]

CI execution-plane review update: keep this PR on pool=bootstrap-ci until Nulang Cloud PR #819 (ci: add Kubernetes + Kueue execution plane for Woodpecker) is deployed and its manual two-step k8s-smoke lane has repeatedly passed on exact requested SHAs. After that qualification, the smallest follow-up here is to change only the agent label to pool: k8s-ci and add explicit backend_options.kubernetes.resources to the existing single CI step; preserve the exact-HEAD check and repository-native Make/npm commands. Do not switch this required lane to the Nulang/Firecracker provider yet; #129/#131 still need authoritative real-KVM recovery/long-running-execution evidence.

[dporkka]

Prepared #143 as a manual-only k8s-ci qualification canary stacked on this PR. It preserves this PR's bootstrap-ci lane unchanged, exact-HEAD binds before toolchain installation, and runs only the repository-native static gates with explicit Kubernetes CPU/RAM requests. Do not retarget this required fallback lane until the shared Nulang Cloud VKE/Kueue execution plane has repeated smoke/canary execution and cleanup evidence.

[dporkka]

CI convergence update (2026-10-05): draft PR #156 is now the preferred successor to this bootstrap lane.

#136 established the correct owned bootstrap-ci fallback and exact-HEAD invariant, but it duplicates the GitHub workflow's toolchain/command orchestration directly in Woodpecker. #156 keeps the same repository-native Make/npm gates while moving the portable execution environment into Dagger v0.20.3, matching the already-operated Adacavo Woodpecker+Dagger pattern.

Do not close or merge-supersede #136 yet. Dev Plane is not currently producing any Woodpecker status context, so #156 first needs repository activation/webhook repair and one real exact-head bootstrap-ci execution. Nulang Cloud #826 adds an operator-only idempotent activation/repair helper; its targeted ci/woodpecker/pr/control-plane regression is green on the real bootstrap pool.

Once #156 executes successfully, prefer #156 and retire this duplicated-command lane rather than maintaining two verification definitions.