Add Gitea Actions sibling workflow

Reusable workflow at .gitea/workflows/kibot.yml — mirrors the
GitLab-side jobs (preflight, fabrication, astable_dev/main).
Same scripts, same Astable upload contract.

GitLab CI reads /kibot-ci.yml; Gitea Actions reads
/.gitea/workflows/kibot.yml. They don't trip over each other,
so projects on either platform submodule the same kicad-ci repo
and pick up the appropriate orchestrator.

Per-project caller snippet documented in
.gitea/workflows/README.md.

.gitea/workflows/README.md

@@ -0,0 +1,60 @@
+# Gitea Actions — KiCad CI
+
+Sibling implementation of `kibot-ci.yml` (GitLab) for projects hosted
+on Gitea. Same fab pipeline, same Astable upload contract; only the
+orchestration layer differs.
+
+## Per-project setup
+
+In each PCB project's repo, create `.gitea/workflows/ci.yml`:
+
+```yaml
+name: KiCad CI
+on:
+  push:
+    branches: [dev, main]
+  pull_request:
+    branches: [dev, main]
+
+jobs:
+  kicad:
+    uses: Micromelon/kicad-ci/.gitea/workflows/kibot.yml@main
+    with:
+      project_name: m100301-dengus_cab_tablet_mainboard
+    secrets:
+      ASTABLE_URL: ${{ secrets.ASTABLE_URL }}
+      ASTABLE_API_TOKEN: ${{ secrets.ASTABLE_API_TOKEN }}
+```
+
+Adjust `project_name` per project. The PCB project's `.gitlab` (sic)
+submodule still points at the same `Micromelon/kicad-ci` repo —
+keeping the submodule path identical to the GitLab side means
+`scripts/upload-bom.sh`, `configs/*.kibot.yaml`, etc. are reachable
+from both platforms without per-platform path branching.
+
+## Secrets
+
+Set at the org level (Org → Settings → Actions → Secrets) so every
+PCB repo picks them up automatically. Same shape as the GitLab CI
+variables on `Micromelon/`:
+
+- `ASTABLE_URL` — e.g. `https://astable.timhadwen.com`
+- `ASTABLE_API_TOKEN` — `ast_…` minted at `/manage/api-tokens`
+
+## Differences vs the GitLab side
+
+- Each stage's artifacts are separate (`Fabrication`, `Fabrication-bom`,
+  `Fabrication-3d`, …) and the astable jobs `download-artifact` them
+  all into one directory. GitLab pools them automatically; Gitea
+  Actions doesn't.
+- Version extraction reads from the commit message (main branch) or
+  the PR title (MR-to-main). Same V-token rule.
+- Panel job uses `continue-on-error: true` to match GitLab's
+  `optional: true` semantics.
+
+## Reusable-workflow support
+
+Requires Gitea ≥ 1.21 (with Forgejo Actions / Gitea Actions support).
+If your runner is older, vendor this file into each PCB project's
+`.gitea/workflows/` directly (drop the `workflow_call:` trigger and
+add a `push:` / `pull_request:` trigger).