quest: plan kix enqueueing ready PRs and quest wait after merges

quest/m0/kix/README.md

@@ -138,4 +138,5 @@ fixes what it finds:
 - [Private repositories](/quest/m0/kix/private.md) - moq-dev/moq.pro enrolls, visible only to signed-in users who can read it
 - [Job sandbox](/quest/m0/kix/sandbox/README.md) - head approval for kix-pushed heads, and opencode sandboxed
 - [Web execution](/quest/m0/kix/execution.md) - spawn and iterate through the UI, ending in contribution PRs
+- [Merge queue enqueue](/quest/m0/kix/enqueue.md) - kix enqueues ready PRs into a merge queue instead of only arming auto-merge
 - [Runner review checks](/quest/m0/kix/review-check.md) - runners publish the App's `quest review` check, so their heads land without a human approval

quest/m0/kix/enqueue.md

@@ -0,0 +1,31 @@
+# [S] kix enqueues ready PRs into the merge queue
+
+## Goal
+
+On a base with a merge queue, kix's Worker enqueues a PR whose head it
+lands with `enqueuePullRequest` pinned to that head as soon as GitHub can
+queue it, instead of only arming auto-merge, so kix-landed PRs reach the
+queue even when GitHub fails to move auto-merge PRs into it. While required
+checks are still pending, kix keeps arming auto-merge bound to the head, as
+`quest merge --land` does.
+
+## Plan
+
+Decided 2026-11-02 (maintainer, /quest-plan of the follow-ups from the
+2026-11-02 `/quest-complete` session, raised by
+[moq-dev/quest#385](https://github.com/moq-dev/quest/pull/385)): ✅ plan it,
+m0.
+
+- `landPullRequest` (`cloudflare/src/github/service.ts`) lands a merge-queue
+  base only by arming auto-merge. Since about 2026-09-10, GitHub often never
+  moves such PRs into the queue
+  ([community#209348](https://github.com/orgs/community/discussions/209348)).
+- Share the CLI's split from #385 (`land` in `src/cli/hold.ts`): enqueue
+  with `expectedHeadOid` when the PR is ready, arm auto-merge when checks may
+  be pending, and fall back to enqueueing when GitHub answers that the PR is
+  already in clean status. Move the decision into shared code if both sides
+  can call it, rather than keeping two copies.
+- A refused enqueue (conflict, failing checks) is a job result the runner
+  reports, like any other refused landing; kix doesn't fix it.
+- The [land review](/cloudflare/src/github/review.ts) rule still applies first:
+  kix enqueues only a head with a review that counts on it.

quest/m1/README.md

@@ -26,3 +26,4 @@ earlier "Later work" milestone became m2.
 - [Quest log theme](/quest/m1/theme/README.md) - an MMO-style identity, copy, board, landing page, and CLI output for the demo and launch
 - [Launch material](/quest/m1/launch.md) - README, quickstart, demo, comparison, and launch-post drafts
 - [Workers in a 5-minute cache](/quest/m1/worker-cache.md) - re-plan #276's worker/coordinator split and gate tickets, after confirming the cache premise
+- [quest wait after a merge](/quest/m1/wait-merge-heads.md) - `quest wait` resolves a head that reached the branch by a merge into it

quest/m1/wait-merge-heads.md

@@ -0,0 +1,26 @@
+# [XS] quest wait resolves heads that came from a merge into the branch
+
+## Goal
+
+`quest wait <pr> <sha>` finds when `<sha>` reached the PR's head branch
+even when it got there by a merge into the branch, such as GitHub's
+**Update branch** or a merge queue's merge, instead of failing with
+`cannot resolve push time for <sha>; pass a timestamp with --since`.
+
+## Plan
+
+Decided 2026-11-02 (maintainer, /quest-plan of the follow-ups from the
+2026-11-02 `/quest-complete` session, raised by
+[moq-dev/quest#347](https://github.com/moq-dev/quest/pull/347)): ✅ plan it,
+m1, since agents merge locally and push, so it's rare, and `--since` works
+around it.
+
+- `quest wait`'s setup (`src/cli/wait.ts`) matches the point only among the
+  branch's `push`, `force_push` and `branch_creation` activities. Also
+  accept `pr_merge` and `merge_queue_merge` when resolving the point, the
+  types #347 taught `quest status`'s enabled-head lookup to count as moving
+  the head. Export `BRANCH_UPDATES` from `src/cli/status.ts`, or move it to a
+  module both import, rather than keeping a second list.
+- Use that merge-inclusive list only to find the starting point. The pushes
+  `quest wait` reports keep using the existing push list, so a merge into the
+  branch is never reported as `pushed`, and force pushes print as before.