ci: fix release-please manifest tag handling

[bokelley]

Summary

• Set include-component-in-tag: false so manifest-mode Release Please looks for the existing vX.Y.Z tags instead of adcp-vX.Y.Z.
• Make the pyproject prerelease-normalization step skip cleanly when Release Please reports a PR update but no release PR branch exists.

Why

After #877 switched to manifest mode, Release Please treated package-name: adcp as the component for tag lookup and opened a bogus historical release PR for adcp 6.0.0-beta.1. The repo's existing release tags are componentless (v6.3.0-beta.4), so manifest mode needs to keep component names out of tags.

Validation

• python3 -c 'import json; json.load(open("release-please-config.json"))'
• ruby -e 'require "yaml"; YAML.load_file(".github/workflows/release-please.yml")'
• git diff --check
• pre-commit hooks from git commit

[aao-ipr-bot]

Approving. include-component-in-tag: false is the right manifest-mode escape hatch — undoes the #877 regression while leaving package-name: adcp to drive the changelog header and PR title, which is the right split.

Things I checked

• release-please-config.json:9 — include-component-in-tag: false matches existing tag history. git tag --list 'v*' ends at v6.3.0-beta.4; git tag --list 'adcp-*' is empty. Manifest lookup keyed on "." is unaffected.
• .github/workflows/release-please.yml:42-50 — set -euo pipefail is compatible with the new probe block. git ls-remote --exit-code is guarded by if, so non-zero exit doesn't trip errexit; 2>/dev/null swallows the expected stderr.
• Component-suffixed branch (...--components--adcp) is probed first, base branch second. Order is right: stale component-suffixed branches from #877 may still be on origin, so prefer-suffix-then-fall-back is the correct precedence today.
• ci: conventional prefix matches the diff: workflow + release config only, no public API surface, no source under src/adcp/ touched.

Follow-ups (non-blocking — file as issues)

• Replace the branch probe with fromJSON(steps.release.outputs.pr).headBranchName. release-please-action@v5 exposes the PR head branch directly. Guessing the naming scheme will break again the next time Google renames the convention. Keep the probe only as a loud-failing fallback.
• exit 0 when no branch exists hides a real contradiction. The step is gated on prs_created == 'true' — release-please claiming a PR while no branch exists on origin is the action lying to the workflow, not a benign no-op. Prefer exit 1 with the probed ref names, or at minimum ::warning:: so it surfaces in the run summary.
• Add a release-please --dry-run CI job gated on changes to release-please-config.json / .release-please-manifest.json / .github/workflows/release-please.yml. Would have caught #877 pre-merge and would have confirmed this fix without waiting for the next push to main. Notable that this is the third release-plumbing PR in a row whose Validation checklist only proves the files are syntactically well-formed.
• Close the bogus adcp 6.0.0-beta.1 release PR from #877 manually so release-please does not stay confused about whether it owns it.

Minor nits (non-blocking)

1. No cross-check that the chosen RELEASE_PR_BRANCH matches the version release-please just bumped. If a stale component-suffixed branch lingers on origin, the probe picks it ahead of the live base branch and normalize_pyproject_prerelease.py rewrites the wrong pyproject.toml before pushing. Low likelihood once #877 leftovers clear. .github/workflows/release-please.yml:42-44.

LGTM. Follow-ups noted below.