[Chore] Revise the CLI flags introduced in 0.12.0

This is a tracking parent; its concrete flag decisions must be recorded in the issue body, and each rename, merge, or removal becomes a separate leaf issue. Begin with the named packages under pkg/cmdsetup, banyand, and bydbctl/internal/cmd, then compare their flag registrations with the two flag reference pages and docs/operation/upgrade.md. Done means the review decisions and executable checks are defined for every flag; implementation is not assigned to this parent.

Summary

0.12.0 shipped a batch of new command-line flags. They went into the release without a single review pass over their names, types, defaults, per-role coverage, and documentation. This issue marks that review as outstanding work: revise the flags introduced in 0.12.0 before the 0.12.0 milestone is considered settled.

This is a tracking parent, not an implementation contract. It owns the completion criteria below. The review pass it asks for decides the concrete changes; every rename, merge, or removal then becomes its own executable leaf issue. Do not queue this issue for automated implementation.

Boundary

The CLI flag contract of the shipped binaries:

• banyand standalone, banyand data, banyand liaison — the flags each role accepts, their types, defaults, and help text.
• bydbctl data export — the flags the export command accepts, their types, defaults, and exit codes.

What a caller may rely on: a flag name, its type, its default, and the wording of its help text. What stays free to change without an issue: the implementation behind a flag, and the feature the flag configures.

Flags in scope

The surface added in this release, to be confirmed against the release diff when the review pass starts:

Server (banyand):

• --bydbql-plan-cache-size, --bydbql-plan-cache-max-bytes, --bydbql-plan-max-compiles, --bydbql-plan-max-in-flight
• --stream-export-snapshot-path, --measure-export-snapshot-path, --trace-export-snapshot-path, --property-export-snapshot-path

Client (bydbctl data export):

• --dry-run, --output-format / -o, --strict-coverage, --selector, --parallelism, --nodes, --plan

Requirements

• R1. Every flag introduced in 0.12.0 has one recorded decision — keep, rename, merge, or remove — written in this issue body (edit the body; do not leave it in a comment), together with the reason.
• R2. A retained flag's name follows the conventions of the flags around it: kebab-case, <subject>-<qualifier> shape, no abbreviation the surrounding CLI does not already use, and no name whose meaning shifts between roles.
• R3. One knob is not spelled as several near-duplicate flags unless the issue body says why the split is required. The four --<catalog>-export-snapshot-path flags are the case in point.
• R4. A retained flag has one documented default, equal to the code default, and a type that rejects an invalid value at parse time with a usage error — a value that means "unbounded" or "automatic" is expressed so that 0, abc, and -1 are each rejected rather than silently falling back to a default.
• R5. A retained flag is documented in docs/operation/configuration.md (server) or docs/interacting/bydbctl/bydbctl.md (client) with the same name, default, unit, and wording as --help prints.
• R6. A flag is registered in every role where the feature it configures runs, and banyand <role> --help lists it in each of those roles.
• R7. A flag that is renamed or removed after having shipped in a released version is recorded in docs/operation/upgrade.md with the old name, the new name, and the behaviour change.

Acceptance criteria

• Every requirement above is checked by something that can be run, and the check fails before the corresponding leaf merges and passes after it.
• The final flag names and defaults of banyand standalone --help, banyand data --help, banyand liaison --help, and bydbctl data export --help agree with docs/operation/configuration.md and docs/interacting/bydbctl/bydbctl.md.
• End to end: a node started with the revised flags answers bydbctl data export --dry-run --nodes <addr> and renders its report; the same command with an invalid flag value exits with the usage exit code and the message the issue names.
• Per role: for each role the flag belongs to, the flag is accepted by that role's binary and rejected by a role it does not belong to.
• Compatibility: any renamed or removed flag that shipped in a released version appears in docs/operation/upgrade.md.

Scope

• Packages: pkg/cmdsetup, banyand/liaison/grpc, banyand/stream, banyand/measure, banyand/trace, banyand/property, bydbctl/internal/cmd.
• Docs: docs/operation/configuration.md, docs/interacting/bydbctl/bydbctl.md, docs/operation/upgrade.md.
• Out of scope: the behaviour of the features the flags configure (the export session protocol, the measure QL plan cache) beyond what the flag contract itself states; flags that earlier releases already shipped; any new feature.

Size audit

• Classification: tracking parent
• Boundary: the CLI flag contract of the banyand standalone/data/liaison binaries and of bydbctl data export — names, types, defaults, and the documentation stating them.
• Production activation: banyand <role> --help, bydbctl data export --help, and the two flag reference pages.
• RED test: a flag-contract test asserting each documented flag is registered on the role's flag set with the documented default; it does not exist today, and each leaf adds the assertion that fails before it.
• End to end: bydbctl data export --dry-run against a running node, and the rejection of an invalid flag value.
• Format/lifecycle scope: none — no persisted bytes and no wire format change; the flag contract is a CLI surface.
• Fixtures and oracle: none; the expected values are the flag names and defaults this issue states.
• Focused suites: make test-ci PKG=./pkg/cmdsetup ./bydbctl/internal/cmd.
• Dependencies present on main: yes — the 0.12.0 flags are registered in pkg/cmdsetup, banyand/liaison/grpc, banyand/{stream,measure,trace,property}, and bydbctl/internal/cmd.
• Decision: tracking parent. The review pass names the concrete changes; each rename, merge, or removal becomes its own executable leaf, ordered by dependency.