accept, accept --batch and the inbox read authority from the union of branch and base #94

Ruling: Session B close-out §3 question 6 (docs/sessions/2026-10-session-b.md), ruled 5 October 2026: "yes. accept, accept --batch and the inbox read keys, grants and policy from the union of branch and base, as verify --base does." Recorded in docs/signing-rulings-2026-10.md, "Session B close-out (ruled 2026-10-05)". Spec: docs/ledger-format-v1.md §3.10.5 (trusted bindings) and §3.10.6 ("Branches"). Size: M. Depends on: #92 merged. Must land: before the Varve import (#73) is run with more than one branch open.

Why

ledger verify --base <ref> computes landing against the base and reads the base's log files and sidecars that a branch checkout lacks (landing::Landing::compute, verify::Options::base). The signing verbs do not. They read authority from the checkout alone:

• the signer's key bindings (author/sign_ops.rs);
• the grants and policy behind under (author/acceptance_ops.rs decision_authority, author/batch_accept.rs resolve);
• the inbox's grant column (inbox::list::grant_on, over revision::load_at of the branch).

The consequence, found in #92: a holder who rotates keys on the default branch cannot sign on a branch cut before the rotation. accept --batch refuses there until the branch merges the default branch, even though verify --base would pass the result.

What to build

• accept and accept --batch take --base <ref>. They read key bindings, grants, grant acceptances, revocations and policy from the union of the branch and the base, with the same landing order verify --base uses.
  • The default must not rely on origin/HEAD. Either it is explicit, or it uses Landing::default_base, as verify does. The PR states which.
• The inbox passes --base <remote>/<default> to every accept --batch it runs, as it already does to verify. grant_on resolves over the same union.
• Terminating entries on the base apply on the branch: a key closed, a grant revoked, or a policy filed on the base. So a branch cannot be used to sign with something the base has ended.
• No format change. This is how the verbs read the store, not what they write.

Tests

• Rotate the key on main after the branch is cut. inbox accept signs on the old branch, and verify --base origin/main --export is green. This is the case #92's an_acceptance_under_a_since_closed_key_is_affirmed_in_the_same_batch currently avoids by rotating first.
• A key revoked on the base is refused on the branch.
• A grant revoked on the base is refused on the branch.
• A policy filed on the base governs the branch.
• Without --base and with no origin/HEAD, the verb behaves as the PR states, and a test pins it.