docs(contributing): releasing.rst documents the cascade guard with the rejected spelling

[JarryShaw]

docs/source/contributing/releasing.rst:176-177 states the cascade guard with the wrong spelling — the one the workflow explicitly rejects. Found by a cross-review on #957.

What the page says:

The three jobs here do the same for each of their own direct dependencies: !cancelled() && needs.<job>.result != 'failure'.

No job in create-release.yml uses that form. tag (:447), pypi (:525) and conda (:625) all spell it:

!cancelled() && needs.version_check.result == 'success' &&
(needs.github.result == 'success' || needs.github.result == 'skipped') && ...

The only two occurrences of != 'failure' in the file are comments explaining why it is not used, at :119 and :124-128:

… rather than the sibling files' != 'failure' -- != 'failure' alone still admits cancelled, and a cancelled tag would send conda into its actions/checkout with ref: conda-<version>+0 for a tag tag never pushed, trading a clean skip for a checkout failure.

So the page documents a guard that would reintroduce the defect the real guard was written to avoid. tests/project/test_release_gates.py:624 pins this directly — assertNotIn(f"needs.{dep}.result != 'failure'", condition) — so the behaviour is tested and only the prose disagrees.

The surrounding paragraph is right about everything else, including that cron-vendor.yml, deploy-pages.yml and cron-conda.yml do use != 'failure' for needs.unit-tests.result. The error is confined to the sentence generalising that to the three publishing jobs. Fix is to give the two-state spelling and say why it differs from the sibling files.

Note #953 currently owns releasing.rst and is open with a cross-review verdict, so this wants either its own change after #953 merges, or a deliberate decision to fold it in.

[JarryShaw]

Blocked on #953, and the blocker is checkable rather than remembered:

gh pr view 953 -R JarryShaw/PyPCAPKit --json state,mergedAt -q '"\(.state) \(.mergedAt)"'

While that returns OPEN, this stays blocked. #953 is the open prose sweep that owns docs/source/contributing/releasing.rst; it carries a review: good-to-go verdict at 7c6b8a681 and editing the same file now would turn a reviewed diff into an unreviewed one.

When it returns MERGED, this unblocks and wants its own one-paragraph change.

[JarryShaw]

Unblocked — #953 merged as 31b01dbc5 (04:25:22Z), and it did not fix this. The blocker I posted above is spent; releasing.rst is now free to edit.

Re-verified on current main rather than from memory, :168-175:

The three jobs here do the same for each of their own direct dependencies: !cancelled() && needs.<job>.result != 'failure'.

A verification trap worth recording for whoever picks this up: grep "!= 'failure'" docs/source/contributing/releasing.rst returns only :171, which is the correct occurrence — the one about needs.unit-tests.result in the sibling workflows. The wrong one wraps across a line break (needs.<job>.result != / 'failure'), so a single-line grep misses it. Read the paragraph, or normalise whitespace first.

Picking this up now.