Canonicalize registry docs and read-only ops

docs/gitea-package-registry.md

@@ -0,0 +1,50 @@
+# Gitea Package Registry
+
+This is the canonical Railiance operating note for the current Gitea Python
+package registry. Compatibility pointers remain in `railiance-apps` while
+deploy-capable Gitea Helm and manifest files still live there.
+
+Gitea package support is enabled by
+`/home/worsch/railiance-apps/helm/gitea-registry-values.yaml`. That overlay is
+applied after the encrypted base values by `make gitea-deploy` and enables both
+container packages and Python packages.
+
+## Python Packages
+
+Publish Python wheels to the organization package endpoint:
+
+```bash
+python -m build
+TWINE_USERNAME=<gitea-user> \
+TWINE_PASSWORD=<package-token> \
+python -m twine upload \
+  --repository-url https://gitea.coulomb.social/api/packages/coulomb/pypi \
+  dist/*
+```
+
+Install from the simple index:
+
+```bash
+pip install \
+  --extra-index-url https://<gitea-user>:<package-token>@gitea.coulomb.social/api/packages/coulomb/pypi/simple/ \
+  issue-core
+```
+
+For CI, store the token as a secret and inject it into the package index URL at
+build time. Do not commit tokenized index URLs.
+
+## issue-core Migration
+
+The portable deployment path for `vergabe-teilnahme` is:
+
+1. Release `issue-core` from its source repo as a wheel, for example `0.2.0`.
+2. Publish the wheel to the Gitea Python package registry.
+3. Keep `vergabe-teilnahme/pyproject.toml` on a versioned dependency such as
+   `issue-core>=0.2,<0.3`.
+4. Regenerate `vergabe-teilnahme/uv.lock` from the Gitea PyPI registry after the
+   package exists there.
+5. Build the image on a clean runner that has no sibling `issue-core` checkout.
+
+Registry endpoint ownership lives in `railiance-forge`; the package release and
+application dependency lock belong to the `issue-core` and `vergabe-teilnahme`
+source repos.