Give the DevOps stack its own build, so its PRs are actually checked

[ChrisonSimtian]

Closes the gap in Homelab #415. This repo had no .github directory at all, so a PR against it merged with zero checks — its shapes were only ever validated because someone happened to run the superproject's build by hand from a working tree with the submodule checked out. A malformed shape would merge clean and surface one repo away from the change that caused it.

That's not hypothetical: the Forgejo OIDC shape (#20) merged yesterday with no checks reported.

#415's table is out of date

It describes an opt-in validate.yml calling the superproject's reusable _validate-shapes.yml. SmartHome has since replaced that with a Fallout-driven build.yml that runs the same portable validator through the repo's own build — so ./build.sh locally and CI run the identical target, and the release bundle is proven on every PR rather than at release time. This ports the newer pattern.

.config, .husky, CLAUDE.md and README.md were already here and byte-identical to SmartHome's, so this is the missing half rather than a fresh start.

Running it caught what reading it didn't

A case-sensitive grep for SmartHome missed four lowercase references, so the first bundle came out as:

bundled dist/smarthome-0.1.0.tar.gz    ← from a repo called DevOps

Wrong archive name, wrong release asset, wrong CI artifact name. Fixed and re-run:

bundled dist/devops-0.1.0.tar.gz (19647 bytes)

# DevOps stack — 0.1.0
- Repo: Chrison-Homelab/Homelab.Stacks.DevOps
| cloudflared | 3004 |   | forgejo-runner | 3001 |   | forgejo | 3000 |
| github-runner | 3002 |  | newt | 3005 |          | shell | 3003 |

One thing I left deliberately imperfect

BundlePaths() stays hand-maintained, ported as-is rather than made clever. It now carries a warning, because a new asset directory not listed there is silently left out of the bundle rather than failing the build. It's the one part of this harness that rots; shell-assets is currently the only entry that matters.

⚠ One thing I could not verify

Whether this repo is inside the SCHEMA_RO_PAT org secret's visibility scope. Reading that needs admin:org, which I don't have, and there's no repo-level secret here.

So this PR's own CI run is the test. If build fails at the validator download step, the fix is the command in the superproject's CLAUDE.md — grant the secret to this repo. Flagging rather than discovering it silently.

Note on ordering

Per #415's warning: this repo hosts github-runner, which the superproject's CI depends on. Nothing here touches the runner or its shape — this only adds a build that runs on ubuntu-latest, so a failure here cannot take the fleet's CI with it.