docs(P00): clarify+research+plan — v0.15 CI release pipeline

Key finding: CoreCI podman executor appends sh -c to step image,
which conflicts with kaniko's /kaniko/executor entrypoint. Container
publishing moves to Gitea Actions workflow (supports entrypoint
override). CoreCI keeps validate/build/test/release (tarball).

---ci---
project: orca
phase: 0
milestone: v0.15
status: plan
---/ci---

.ciagent/CHECKPOINT.json

@@ -1,6 +1,6 @@
 {
   "phase": 0,
-  "stage": "specify",
+  "stage": "plan",
   "milestone": "v0.15",
   "milestone_slug": "ci-release-pipeline",
   "phase_role": "pre_execution",

.ciagent/CLARIFY_v0.15.md

@@ -0,0 +1,51 @@
+# CLARIFY + RESEARCH + PLAN v0.15: CI Release Pipeline Fix
+
+## Decisions
+
+| ID | Decision | Rationale | Confidence |
+|----|----------|-----------|------------|
+| D-264 | Secret name = `PAT_TOKEN` (not `GITEA_PAT`) | Gitea reserves `GITEA_` prefix for built-in secrets | 1.0 (validated) |
+| D-265 | Use `tea actions secrets create` CLI | Operator instruction: no API | 1.0 (validated) |
+| D-266 | Container publishing in Gitea Actions, not CoreCI | CoreCI's podman executor appends `sh -c` which conflicts with kaniko's `/kaniko/executor` entrypoint. Gitea Actions `container:` supports `options: --entrypoint` | 0.95 |
+| D-267 | kaniko `executor:debug` image | Includes `/bin/sh`; Gitea Actions can override entrypoint to `/bin/sh` then run kaniko via shell | 0.90 |
+| D-268 | `coreci run` for validate/build/test/release (tarball); Gitea Actions for container publishing | Clean separation: CoreCI owns the pipeline, Gitea Actions owns the trigger + container publish | 0.95 |
+
+## Research: CoreCI podman executor entrypoint issue
+
+CoreCI's `internal/runner/podman_executor.go:48-51`:
+```go
+args = append(args, image)  // e.g. gcr.io/kaniko-project/executor:debug
+if job.Invoke != "" {
+    args = append(args, "sh", "-c", job.Invoke)
+}
+```
+This produces: `podman run ... <image> sh -c "<commands>"`
+With kaniko:debug (entrypoint `/kaniko/executor`), the actual command is:
+`/kaniko/executor sh -c "<commands>"` — kaniko fails (sh is not a kaniko flag).
+
+**Conclusion**: kaniko cannot be used as a CoreCI step image. Container
+publishing must move to the Gitea Actions workflow, which supports
+`container: options: --entrypoint /bin/sh` to override the entrypoint.
+
+## Plan
+
+### Phase 1 (only execution phase)
+
+**Files to create/modify:**
+
+1. `.gitea/workflows/release.yml` — Gitea Actions workflow:
+   - `on: push: tags: ['v*']`
+   - Job 1 `ci`: checkout + install Go + install coreci + `coreci run`
+     (executes validate/build/test/release from .coreci.yml)
+   - Job 2 `container-orca`: checkout + kaniko build+push orca image
+     (needs job 1; uses `container: gcr.io/kaniko-project/executor:debug`
+     with `options: --entrypoint /bin/sh`)
+   - Job 3 `container-traefik`: checkout + kaniko build+push orca-traefik image
+     (needs job 1; same kaniko approach)
+
+2. `.coreci.yml` — remove `container-publish` and `container-publish-traefik`
+   steps (they now live in the Gitea Actions workflow). Keep the
+   `gitea-release` step (tarball + Gitea release).
+
+3. `scripts/trigger_coreci.sh` — add tag ref handling (or document that
+   Gitea Actions is the trigger; the hook is for branch-push CI only).