chore(ci): clear JSDelivr cache for Ionic Next - #29121

…#31478)

Issue number: internal

---------

<!-- Please do not submit updates to dependencies unless it fixes an
issue. -->

<!-- Please try to limit your pull request to one type (bugfix, feature,
etc). Submit multiple pull requests if needed. -->

## What is the current behavior?
<!-- Please describe the current behavior that you are modifying. -->

Currently, the `update-package-lock` job fails the release with `ETARGET
No matching version found for @ionic/core@^9.0.x`. Since 9.0.4 npm
processes publishes asynchronously, so `npm publish` returns before the
version resolves. The registry recorded `@ionic/core` 4s after the
publish step on 9.0.3, but 5m11s on 9.0.4 and 5m10s on 9.0.5, against a
near constant 5m04s gap from publishing to that job, so the last two
releases each missed by about six seconds and needed the job re-run by
hand.

Separately, `purge-cdn-cache` has never done anything. A missing comma
before the `@next` CSS entry made the body invalid JSON, so jsDelivr
rejected every purge with `InvalidContent` while `curl` exited 0 and the
step stayed green. That has been true since ionic-team#29121.

## What is the new behavior?
<!-- Please describe the behavior or changes that are being added by
this PR. -->

The `Bump Package Lock` step is split into `Resolve Package Locks`,
which retries `lerna exec "npm install --package-lock-only
--prefer-online"` every 15s against a 900s wall clock deadline, and
`Commit Package Locks`, which does the commit and the push. We retry the
install rather than probing with `npm view` first, because the two read
separately cached documents and a passing probe wouldn't mean the
install resolves. The `--prefer-online` flag is required because a
failed install caches the version-less packument locally for 300s, so
plain retries never reach the registry. The bound is wall clock rather
than an attempt count since one attempt costs about 45s and a fixed
count would overrun `timeout-minutes`.

The `purge-cdn-cache` job now runs after `update-package-lock` and gates
on a new `resolved` output rather than the job's result, so a failed
lockfile push still purges but an unresolved version doesn't. The comma
is fixed and the step checks the HTTP status, failing on a 4xx because a
bad payload is otherwise silent, and warning on anything else so a
jsDelivr outage doesn't fail a release.

## Does this introduce a breaking change?

- [ ] Yes
- [X] No

## Other information

<!-- Any other information that is important to this PR such as
screenshots of how the component looks before and after the change. -->

The `release.yml` workflow only runs on a real production release, so I
couldn't test this end to end. I ran each step's shell against stubs for
the failure paths, but the first real signal will be the next release.