A release-please bump of a file:// library chart leaves 41 dependents with a stale Chart.lock and breaks chart publishing on main

### Context

Merging the release-please PR #888 (2026-09-02, `15cfbecb`) broke **Publish Charts to OCI** and **Release Helm Charts** on `main`:

```
Error: can't get a valid version for dependency common
```

Mechanism: release-please bumped `charts/common/Chart.yaml` `2.31.4 → 2.31.5` and touched no `Chart.lock`. **41 charts** pin `common` through `repository: file://../common`, and `helm dependency build` — the command both workflows run — refuses to re-resolve a lock whose pinned version no longer exists. `helm dependency update` would; `build` will not, by design.

This is **latent in the pipeline**, not specific to #888: it fires every time release-please bumps a `file://` library chart (`common`, `bjw-template`, …), because nothing regenerates the dependents' locks. It went unnoticed until now because `common` had not been bumped by a release since the locks were introduced. ArgoCD deploys from the OCI path (ADR-0055), so the failure blocks every chart deploy until someone relocks by hand — which is what #1088 does for this instance.

### Acceptance Criteria

1. A `common` (or any `file://` library) version bump on `main` cannot leave a dependent's `Chart.lock` stale. Either:
- (a) release-please's `extra-files` / a post-release job runs `helm dependency update` for every dependent and commits the locks in the same release PR, or
- (b) `publish-charts-oci.yml` and `release-helm-charts.yml` run `helm dependency update` instead of `build` for `file://`-only dependencies, with a CI assertion that the resulting lock matches what is committed (so drift is caught on the PR, not on `main`).
2. A test proves it: bump `common` on a branch without relocking → CI fails **on the PR** with a message naming the stale charts, not on `main` after merge.
3. The fix is recorded in `docs/` next to the ADR-0055 publish path so the next person hitting "can't get a valid version" finds it.

### Out of Scope

The one-off relock for 2.31.5 (#1088). Changing how `common` is versioned.

### Human accountable owner

@stephane-segning

### AI Usage Declaration

- [x] AI-assisted — diagnosed and drafted by Claude Code (Fable 5.1) after merging #888 on the maintainer's instruction; the failure, the 41-lock count and the `build`-vs-`update` behaviour were re-verified by the maintainer before filing.

Read publish-charts-oci.yml and release-helm-charts.yml first, then inspect the dependent charts' Chart.yaml and Chart.lock files and the release-please configuration used by PR #888. Reproduce the stale-lock case by bumping common without relocking. Done means PR CI names every stale dependent, the release or publish path handles file:// dependencies safely, and the ADR-0055-adjacent docs explain the behavior.

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