fix(release): self-heal the release-please "untagged, merged" abort

[JSONbored]

Summary

Root cause traced as far as possible into release-please's own source: createReleases() (the step that actually tags a merged Release PR) sometimes finds nothing to tag, and createPullRequests() then aborts every subsequent run without ever completing the tag. Confirmed live across two separate linked-versions release cycles this session (#7127, #7133), both requiring a manual dispatch of each publish-*.yml workflow plus manually flipping the merged PR's autorelease: pending label. This matches several long-open, unresolved upstream issues (googleapis/release-please#1946, #1444, #1406 -- same exact message), so it isn't something fixable from this repo's config alone.

Adds a reconcile-stale-releases job that runs after every release-please attempt, independent of its outputs (which are unreliable exactly when this bug is in play):

• Compares each package's committed package.json version against what's actually live on npm, and dispatches that package's publish workflow whenever they disagree -- the same "bare manual dispatch" human-override path each publish-*.yml already documents, just triggered automatically instead of by a human noticing red CI on an unrelated PR days later.
• Engine publishes first and is awaited before mcp/miner (they carry a real runtime dependency on it, and their own isolated pack/smoke-test resolves @loopover/engine from the real npm registry, so it fails with ETARGET if engine hasn't actually published yet -- confirmed live when I first tried dispatching all three in parallel).
• Once every package is confirmed live, flips any merged PR still carrying autorelease: pending to autorelease: tagged, unsticking release-please's own tracking for its next run.

Real npm publishes still go through the same environment: release required-reviewer gate as always -- this doesn't remove that security control, it just eliminates the diagnostic/dispatch/label-cleanup toil around it.

Side effect I verified is safe and beneficial: running the version-comparison logic locally against this repo's real current state found one ancient, silently-stuck instance of the exact same bug (engine v1.0.0's Release PR, still autorelease: pending since long before this session) -- the new job's cleanup step will resolve that too.

Test plan

• npm run actionlint -- clean
• Extracted both run: scripts and ran bash -n on each -- syntax valid
• Ran the actual version-comparison script for real against this repo's live state: correctly identified all 4 packages as already in sync and dispatched nothing (safe to execute as a real validation since nothing was out of sync)
• Workflow-only change; not measured by Codecov. Real verification: the next release-please abort should self-resolve within this same job's run instead of needing manual intervention.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.75%. Comparing base (c060b2a) to head (240f29c).
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #7149   +/-   ##
=======================================
  Coverage   93.75%   93.75%           
=======================================
  Files         692      692           
  Lines       68832    68832           
  Branches    18781    18781           
=======================================
  Hits        64535    64535           
  Misses       3302     3302           
  Partials      995      995           

Flag	Coverage Δ
shard-1	43.75% <ø> (ø)
shard-2	36.91% <ø> (ø)
shard-3	33.14% <ø> (ø)
shard-4	34.44% <ø> (ø)
shard-5	32.27% <ø> (+<0.01%)	⬆️
shard-6	45.90% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.