fix(ci): chart publishing has been silently broken since v5.0.0 — release-please tags with GITHUB_TOKEN, which never fires helm-oci.yml

`helm-oci.yml` has not run since `v5.0.0` (2026-08-25), even though `v6.0.0`, `v7.0.0`, `v8.0.0`
and `v9.0.0` were all tagged and pushed. Confirmed:

```
$ git ls-remote --tags origin | grep -E 'v[5-9]\.0\.0$'
… refs/tags/v5.0.0 v6.0.0 v7.0.0 v8.0.0 v9.0.0

$ gh run list --workflow=helm-oci.yml -L 3
2026-08-25 v5.0.0 success ← newest run
2026-08-19 v3.7.0 success
2026-08-17 v3.6.0 success

$ gh api /orgs/ADORSYS-GIS/packages/container/charts%2Flightbridge-authz-stack/versions
… 3.7.0, 5.0.0 ← nothing after 5.0.0
```

## Cause

`ci.yml`'s release job runs release-please with
`token: ${{ secrets.RELEASE_PLEASE_TOKEN || secrets.GITHUB_TOKEN }}`. Its own comment already
names the consequence of the fallback:

> A PAT (RELEASE_PLEASE_TOKEN) lets the release PR trigger CI and its tag fire the publish jobs;
> falls back to GITHUB_TOKEN until it exists.

A tag created with `GITHUB_TOKEN` does **not** fire a `push: tags` workflow — GitHub's recursive
workflow guard. So `helm-oci.yml` silently stopped firing the moment that PAT stopped being
available (expired, revoked, or never renewed), somewhere between v5.0.0 and v6.0.0.

## Impact

Production `lightbridge-app` was pinned to chart `5.0.0` — four majors behind the repo — because
no newer chart had ever been published to pull. Found while shipping #661; `10.0.0` was published
by a manual `workflow_dispatch` of `helm-oci.yml` on the `v10.0.0` tag, and the ArgoCD pin was
moved in ADORSYS-GIS/ai-helm#1093.

Nothing failed. No workflow went red, no alert fired, no job was skipped-with-a-reason. The
publish simply never happened, and the only way to see it is to notice that the newest run on
`helm-oci.yml` is older than the newest tag.

## Fix

1. Restore `RELEASE_PLEASE_TOKEN` (a PAT or, better, a GitHub App installation token), so tags
fire the publish jobs again.
2. Regardless of (1), **make the silence loud.** The current design has a single point of failure
with no signal. Either:
- have the `release` job in `ci.yml` (which already runs on the release commit, with
`release_created == 'true'`) dispatch `helm-oci.yml` directly via
`gh workflow run helm-oci.yml --ref ${{ needs.release-please.outputs.tag_name }}`, removing
the dependence on tag-push semantics entirely; **or**
- add a scheduled check that fails when the newest published chart version in GHCR is behind
`.release-please-manifest.json`.
3. Consider back-publishing 6.0.0–9.0.0 for reproducibility, or explicitly document that those
chart versions were never released.

Start with ci.yml's release job and helm-oci.yml, especially how release-please creates tags and how the publish workflow is triggered. Verify the current RELEASE_PLEASE_TOKEN/GITHUB_TOKEN behavior and compare the newest tag, GHCR chart version, and .release-please-manifest.json. Done means chart publishing is triggered or monitored so future releases cannot silently skip it.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.