Semantic versioning for internal npm package

We have:

Main project X (Angular app) Helper package P (pure JavaScript internal package)

Package P is hosted on our private npm registry and consumed by project X through package.json.

Our releases are managed as fixed product versions like 5.2.2, decided by PMs.
For every release, we create permanent branches such as release/5.2.2.

These branches permanently diverge from master/main. Once created, nothing from master should ever flow into them again except explicitly cherry-picked fixes.

For each release branch:

Package P is published with the same version number as the release itself (example: 5.2.2)

If changes are needed in package P during that release cycle, we currently:

unpublish the package republish it again with the same version number

Because of this, project X only updates the dependency version once during branch creation.

Several people from Infra/DevOps have recommended following proper semantic versioning instead of overwriting the same npm version repeatedly.

However, my concern is operational overhead:

every new publish of package P would require updating package.json in project X this could happen multiple times a week during active release stabilization it feels noisy and repetitive for release branches

What is the recommended way to manage internal npm packages in a release-branch-based workflow like this?

Should we:

follow strict semantic versioning (5.2.2-rc.01, 5.2.1-rc.02 etc.) and update dependencies frequently? (This would mean change package.json of project P each time a new build is release) use dist-tags? automate dependency bumps somehow? or is republishing the same version acceptable for internal/private registries?