docs(rules): document the buildtime/public registry split

Future-proofs against well-meaning "fixes" that would re-align inconsistent
hostnames. CI keeps pushing to gitea.siegeln.net; runtime defaults speak
registry.cameleer.io (the public alias of the same registry). Both forms
of the same image coexist intentionally during the institutionalization
period.

- CLAUDE.md: new "Registry naming (buildtime vs public)" section between
  Related Project and Modules; loader-image default mention now says
  registry.cameleer.io with an inline cross-reference; license-API note
  flags that com.cameleer:cameleer-common stays on the agent repo's
  groupId until that project follows the same flip
- .claude/rules/cicd.md: registry line now names both hostnames and points
  at the new CLAUDE.md section

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

.claude/rules/cicd.md

@@ -15,7 +15,7 @@ paths:
 - UI build script (`ui/package.json`): `build` is `vite build` only — the type-check pass was split out into `npm run typecheck` (run separately when you want a full `tsc --noEmit` sweep).
 - Docker: multi-stage build (`Dockerfile`), `$BUILDPLATFORM` for native Maven on ARM64 runner, amd64 runtime. `docker-entrypoint.sh` imports `/certs/ca.pem` into JVM truststore before starting the app (supports custom CAs for OIDC discovery without `CAMELEER_SERVER_SECURITY_OIDCTLSSKIPVERIFY`).
 - `REGISTRY_TOKEN` build arg required for `cameleer-common` dependency resolution
-- Registry: `gitea.siegeln.net/cameleer/cameleer-server` (container images)
+- Registry: `gitea.siegeln.net/cameleer/cameleer-server` (container images — CI push target, internal hostname). The same registry is reachable as `registry.cameleer.io/cameleer/cameleer-server` for customer pulls; the server's compiled-in image defaults target the public alias. See `CLAUDE.md` § Registry naming.
 - `cameleer-runtime-loader` image (init container that fetches the deployable JAR before the runtime container starts) is built and pushed by **cameleer-saas** CI (`docker/runtime-loader/` in that repo) — it lives alongside the other sidecar/infra images (runtime-base, postgres, clickhouse, traefik, logto). cameleer-server **consumes** the image via `DockerRuntimeOrchestrator` but does not build it. Cross-repo contract is regression-tested by `LoaderHardeningIT` here, which pulls the published `:latest` and asserts exit 0 under the orchestrator's hardening contract.
 - K8s manifests in `deploy/` — Kustomize base + overlays (main/feature), shared infra (PostgreSQL, ClickHouse, Logto) as top-level manifests
 - Deployment target: k3s at 192.168.50.86, namespace `cameleer` (main), `cam-<slug>` (feature branches)