Order release publication channels

[helly25]

Release publication now runs as one visible sequence: GitHub assets first,
then the npm wrapper, then the VS Code Marketplace extension. This prevents a
tag from starting three independent workflows that can leave users seeing a
partially published release.

No package, extension, tag, or GitHub release is created by this pull request.
The npm and Marketplace workflows remain manually dispatchable for targeted
retries after an external-service failure.

AG;DR

Implementation

• Make npm_publish.yml and vscode_marketplace.yml reusable via
  workflow_call, while retaining their existing workflow_dispatch inputs.
• Remove their independent tag-push triggers.
• Have release.yml invoke npm only after its GitHub Release job succeeds,
  then invoke Marketplace publication only after npm succeeds.
• Pass only the credential needed by each called workflow.
• Replace npm's 30-minute polling loop with an exact assertion that all eight
  release assets exist. This also protects manually dispatched retries.
• Update release documentation, the workflow inventory, and the changelog to
  describe the ordered pipeline.

Validation

• git diff --check
• repository pre-commit hooks on all six changed files
  • YAML validation
  • Markdown table alignment
  • release version invariant
  • repository self-reference checks

Publication and retry behavior

The normal tag path is now:

1. build four platform archives and checksums;
2. create the GitHub Release and upload all eight assets;
3. publish and verify @mboworks/coderef;
4. package, publish, and verify mboworks.coderef.

The npm and Marketplace workflows can still be dispatched with an existing tag
to retry only the failed downstream channel. A dry-run release-candidate test
and publisher credential validation remain required before creating v0.6.0.