Improve package backport tooling for routine multi-version support

The current backport process ([docs](https://www.elastic.co/docs/extend/integrations/developer-workflow-support-old-package)) is a 5-step manual procedure built for one-off hotfixes. As more packages adopt format_version 3.5/3.6 and need to maintain fixes on 8.19 (under maintenance until Jan 2027), it's not viable for routine use.

**Gaps:**

1. **Branch creation** - manual Buildkite pipeline today; needs a CLI command or API surface
2. **Cherry-pick + version bump + changelog entry** - no automation; needs a single operation from a commit SHA + target version
3. **Main-branch changelog update PR** - un-automated and easy to skip; needed to keep the integrations changelog site current
4. **Backport branch inventory** - no record of which branches exist and which packages they cover; needed to auto-create backport PRs when changes land in main

**Proposal:**

Build a script or `elastic-package` command that accepts a commit SHA and target version and handles gaps 1-3 as a single operation. Define a backport branch manifest (in-repo file or derivable from branch naming) to power future auto-backport PR creation (gap 4).

**Context:** Near-term unblock for security service integrations adopting 9.4 features while keeping 8.19 support. See elastic/package-spec#1148 for policy context and elastic/package-spec#1163 for long-term options.

**AC:**
- [ ] Branch creation scriptable without manual Buildkite inputs
- [ ] Cherry-pick + version bump + changelog entry runnable as a single command
- [ ] Main-branch changelog update PR automated or explicitly documented
- [ ] Backport branch inventory defined and populated for existing branches