Persist normalized merge authority in batch state

[justin808]

Why

Batch manifests already declare merge authority, but register-batch did not persist it. That left status consumers unable to distinguish an undeclared policy from an explicit none, ask, or automatic policy.

What changed

• Persist merge_authority on the existing batch record; no new record family or storage path is introduced.
• Normalize the internal auto_merge_when_gates_pass spelling to the canonical stored value auto while retaining canonical none, ask, and auto unchanged.
• Expose the optional stored value through the existing batch status --json projection.
• Reject null, boolean, and unknown authority values before writing batch state.
• Cover canonical values, alias normalization, omission, invalid input, persistence, and status projection with CLI regression tests.

Verification

• Focused CLI regressions: 3 runs, 28 assertions, all passing.
• .agents/bin/validate: 55 files inspected, no offenses.
• Independent exact-diff review: clean, no actionable findings.
• Strict security intake: passed.

PR #319 currently overlaps bin/agent-coord; this draft intentionally leaves final current-base integration for later reconciliation rather than modifying or duplicating that work.

Closes #86

Agent details

Implemented by Codex in a dedicated issue worktree and independently reviewed by a separate Codex checker. Human merge authority: none.

[claude]

Maintainability: duplicated enum/alias mapping with no sync check to the canonical schema

BATCH_MERGE_AUTHORITIES and BATCH_MERGE_AUTHORITY_ALIASES hand-duplicate the enum/alias mapping already published as the canonical contract in schema/state/v1/merge-authority/merge-authority.schema.json (see ADR 0011). There's no test tying the two together.

If a future PR bumps the merge-authority vocabulary in the schema file (allowed additively in v1, or via a v2 bump, per ADR 0011) but forgets to update this hardcoded Ruby list (or vice versa), register-batch will silently diverge from the published contract — e.g. rejecting a value the schema/dashboard consider valid, or persisting a value the schema's invalid fixtures say should never be stored. test/merge_authority_contract_test.rb only exercises the schema file directly, and the new CLI tests only exercise these hardcoded Ruby constants, so nothing currently catches this drift.

Consider adding a test that loads the schema's enum/alias values and asserts they match these Ruby constants, so the two stay in sync automatically.

[claude]

Code review summary

Reviewed the actual diff (git diff origin/main HEAD), which touches only bin/agent-coord and test/agent_coordination_cli_test.rb, wiring a merge_authority field into register-batch.

I cross-checked the implementation against the pre-existing published contract for this feature (schema/state/v1/merge-authority/merge-authority.schema.json, docs/adr/0011-merge-authority-state-contract.md, and test/merge_authority_contract_test.rb). The implementation (enum values, alias mapping, "never persist null", optional-by-omission semantics) matches that contract exactly, and the new tests correctly exercise normalization, validation, and status projection. I found no correctness bugs, no removed guards, and no unsafe call-site interactions.

One finding (left inline): BATCH_MERGE_AUTHORITIES / BATCH_MERGE_AUTHORITY_ALIASES in bin/agent-coord hand-duplicate the enum/alias mapping that's supposed to be canonically defined in schema/state/v1/merge-authority/merge-authority.schema.json, with no test tying the two together — so a future schema bump (per ADR 0011) could silently diverge from this Ruby implementation.

No security or performance concerns identified.