Make transaction operation limit configurable (currently hardcoded to 128)

#### Feature Description
I would like to request that the maximum number of operations allowed in a single transaction (currently hardcoded to 128 as of v1.14.0) be exposed as a configurable agent option (e.g., txn_max_ops).

While I appreciate the increase from 64 to 128 in PR #14599, a hardcoded limit presents significant architectural challenges for systems migrating to Consul from other strongly consistent stores like etcd.

Proposed Solution: Introduce a configuration parameter in the agent config, defaulting to 128 to maintain current safety/stability guardrails, but allowing operators to increase this limit.

// Example config
limits {
txn_max_ops = 512
}

#### Use Case(s)

My team is currently migrating a critical control plane from etcd to Consul.

The Problem: In etcd, we frequently commit atomic batches of updates that exceed 128 keys.

The Constraint: Because the limit is hardcoded in Consul, we are forced to break these atomic transactions into chunks (e.g., two batches of 128 and 72).

The Consequence: This breaks the ACID guarantees our application relies on. If the first chunk succeeds and the second fails, our system is left in an inconsistent state.

The issue names no files, tests, or entry points. Review the existing transaction operation limit and agent configuration paths, then determine how the proposed limits.txn_max_ops option should preserve the default of 128 while permitting larger atomic batches. Done means the limit is configurable without changing the default behavior.

Written by the indexing model from the issue text.