update: make spec changes from BatchV1_1

[mvadari]

High Level Overview of Change

Title says it all

Context of Change

XRPLF/rippled#6446

Type of Change

• XLS Update (changes to an existing XLS)

[Copilot]

Pull request overview

Updates the XLS-0056 Batch specification to align with the “BatchV1_1” implementation changes referenced in the linked rippled PR, primarily by tightening BatchSigners rules and clarifying inner-transaction common-field semantics.

Changes:

• Updates XLS metadata and removes the tentative amendment name from the overview.
• Adds/clarifies BatchSigners requirements (sorting, signing payload definition, additional failure conditions).
• Expands “Transaction Common Fields” to specify tfInnerBatchTxn fee and validation/failure behavior.

[dangell7]

Checked this against develop, mostly lines up but a few of the failure conditions drifted from the current implementation:

• 2.1.3 item 7, "BatchSigners is required but is not present (tefBAD_AUTH)": there's no tefBAD_AUTH path for a missing BatchSigners field anymore. If signers are required and the field is absent it falls out of the required-signers match in preflight as temBAD_SIGNER, so this is really the same case as item 6.
• item 8, "contains an invalid signature (temBAD_SIGNATURE)": batch signer sigs are verified in STTx::checkSign now (via checkValidity), so a bad signature surfaces as SigBad -> temINVALID in preflight2, not temBAD_SIGNATURE. That was true when Batch::preflight verified them directly but not anymore.
• the cap: develop has kMaxBatchSigners = kMaxBatchTxCount * 3 = 24, not 8, since an inner can require up to 3 signers now. idk if the spec should track that or stay stock XLS-56, but "greater than 8" doesn't match develop either way.

The signing payload section is spot on though, matches serializeBatch exactly. If the intent is to document BatchV1_1 as released then most of this is fine, just flagging where it diverges from 3.x.