chore(release): version each plugin from its own commits

[openbao-service-broker]

Problem

release-please tracked a single package at the repo root and stamped that one version into the plugin.json of most plugins via extra-files. Any commit anywhere in the repo therefore moved every plugin's version.

A plugin's installed cache directory is named cache/<marketplace>/<plugin>/<version>, so a plugin whose content was byte-identical still got a brand-new directory on every release. Sessions already running resolve plugin paths at startup and re-stat ${CLAUDE_PLUGIN_ROOT} on every hook invocation, so that churn broke them:

PreToolUse:Bash hook error
Failed to run: Plugin directory does not exist: .../git-guards/5.10.1

The plugins absent from extra-files never moved — ai-cli-harness-better-practices (4.24.0), homelab-ops (1.0.0), openbao (4.21.0), slack (5.10.1) — while the repo went 5.11.0 → 5.13.0. That control group is what identified the mechanism.

Change

Each of the 21 plugin directories becomes its own release-please package with its own component, so its version tracks only its own commits.

• Shared settings (release-type, include-v-in-tag, changelog-sections) move to root-level defaults instead of being repeated per package — the config ends up smaller than before, not 21x larger.
• separate-pull-requests stays false, so this still produces one aggregated release PR. The org workflow's auto-merge step reads a single pr output and is unaffected.
• The caller now passes include-component-in-tag: true, so plugins tag as <plugin>-v<version> while the root package keeps v<version>.
• Each component stamps its own plugin.json plus its own entry in the root .claude-plugin/marketplace.json, addressed by a filtered JSONPath.

Also corrects a pre-existing inconsistency: marketplace.json listed every hand-versioned plugin at the repo-wide version rather than its real one.

Merge with main (2026-09-12)

Main released 6.2.1 while this PR was open. The manifest and marketplace.json now record each plugin at the version its own plugin.json carries on main (6.2.1, with the hand-versioned plugins at 4.25.0 / 1.0.0 / 4.21.0), and last-release-sha is re-anchored to the current main head, so the first per-component run bumps nothing that has not changed since 6.2.1.

Verification done

• Config validates against release-please's published schema.
• All 43 extra-file targets resolve to real files under release-please's own addPath rules — a leading / is repo-root-relative, and none trip its illegal-pathing check.
• The filtered JSONPath was exercised against the real marketplace.json with the same jsonpath-plus version release-please bundles: it matches exactly one plugin entry and leaves the others untouched.

Verification that CI cannot do

CI does not run release-please, so the first run on main after this merges is the real test. What to check on that run:

1. It opens exactly one release PR, not 21.
2. That PR bumps only the plugins with commits since their manifest version.
3. Tags come out as <plugin>-v<version>, with the root staying v<version>.
4. Auto-merge is enabled on the release PR.

Reverting is the config + manifest + workflow input; any component tags created would need deleting separately.

🤖 Generated with Claude Code

https://claude.ai/code/session_011KxaQ6Hu73ymuCLtGFJyD7