The model that fits this is trunk-based development with short-lived release branches. main keeps moving, and each release gets its own branch cut from the RC commit. Fixes reach the release branch only by explicit cherry-pick, so nothing merged to main after the cut can leak into v1.6.0.
main: A──B──C──D──E──F──G──H──I ──► (PRs keep merging)
│ ▲
│ └ fix X (merged to main first)
│
release/1.6: C ─────────── X'