Stacked PR cannot be merged into a merge-queue branch

_Repository / PR / stack numbers and the ruleset regex below are fabricated/illustrative; the behavior and error strings are verbatim from a real occurrence. (UI-error screenshot to be attached.)_

## Summary

The bottom PR of a `gh stack` (v0.0.8) stack cannot be merged into a merge-queue-protected branch by any path:

- **API:** `enablePullRequestAutoMerge` and `enqueuePullRequest` both fail: `This pull request is part of a stack and must be merged sequentially using the stack merge API.` That API is not in the public GraphQL schema, and `gh stack` has no `merge` command.
- **UI** ("Merge when ready" → "Confirm enqueue pull request"): fails with `Repository rule violations found — Commit message must match a given regex pattern`. The stack-merge creates a `Merge pull request …` merge commit despite the queue's `rebase` method, so it violates a `commit_message_pattern` rule that only allows `Merge branch …`.

Non-stacked PRs merge through the same queue fine. Only unstacking (`gh stack unstack`) unblocks the merge.

**Working hypothesis:** the trigger is a merge-queue branch whose rules reject merge commits. The stack-merge creates a `Merge pull request …` commit instead of rebasing (as the queue's `rebase` method would), and that commit fails `commit_message_pattern`. Observed: the API rejection and the rule violation. Inferred: that the offending commit is a merge commit (a rebase of the PR's compliant commits would not trip the rule).

## Environment

- `gh` 2.96.0, `gh stack` v0.0.8
- Trunk `main` ruleset: `merge_queue{merge_method: REBASE}`, `pull_request{allowed_merge_methods:["rebase"]}`, `commit_message_pattern` = `^((feat|fix|chore|docs|test|refactor): .+|Merge branch .+)`
- Stack `main ← #101 ← #102`; bottom PR `#101` approved, checks green, up to date with `main`.

## Repro

1. Trunk with a merge queue (rebase) + a `commit_message_pattern` rule forbidding `Merge pull request …`.
2. `gh stack init #101 #102` → `gh stack submit`.
3. Bottom PR green + approved + up to date.
4. Merge it via `gh pr merge #101 --auto --rebase`, the `enqueuePullRequest` mutation, or the UI.

## Expected

Bottom PR enqueues and merges with the queue's `rebase` method, like an equivalent non-stacked PR.

## Actual

- API: `This pull request is part of a stack and must be merged sequentially using the stack merge API.` (`UNPROCESSABLE`, not enqueued).
- UI: `Repository rule violations found — Commit message must match a given regex pattern: …`.

## Likely cause (working hypothesis)

- Enqueue/auto-merge mutations are blocked for any stacked PR, deferring to a "stack merge API" absent from public GraphQL and from `gh stack` (observed).
- The stack-merge creates a merge commit instead of honoring the branch's `rebase` merge-queue method, so its `Merge pull request …` message fails `commit_message_pattern` (inferred from the rule violation).

## Workaround

`gh stack unstack` (PRs keep bases/approvals) → bottom PR enqueues and merges normally.

## Suggested fix

- Have stack-merge honor the target branch's merge-queue method (rebase; no merge commit).
- Expose stack-merge via GraphQL + a `gh stack merge` command.
- Fail earlier with a stack-specific message instead of a generic rule violation.

## Related (no exact duplicate)

- Discussion #172 — "'Merge stack' appears to enqueue only the bottom PR"
- #174 — "Stack merge hangs after partial merge invalidates latest-push approval"
- #169 — "rebase when lower branch was squash merged"

Start by reproducing the stack with `gh stack init`, `gh stack submit`, and the documented merge paths, including `gh pr merge --auto --rebase`, `enablePullRequestAutoMerge`, and `enqueuePullRequest`. Compare the stack-merge behavior with the branch's `REBASE` merge-queue method and the `commit_message_pattern` rule. Done means the bottom stacked PR can enqueue and merge through the queue without a generic rule violation, with any stack-specific API or CLI behavior made explicit.

Rédigé par le modèle d'indexation à partir du texte de l'issue.