Authenticated witness sync cannot be enabled from the command line

A witness that follows an authority can now verify that authority's signature over the state it serves, which is what makes the sync channel resistant to an on-path party altering or withholding entries. Verification happens only when the witness has been told which identity to expect.

That setting can be supplied **only** through the configuration file. The address of the authority to follow has a command-line flag; the identity to expect does not, and has no environment variable either.

## Consequence

A deployment driven entirely from the command line — which the address flag's existence invites — can specify who to follow but cannot specify who to trust. Such a witness runs with verification disabled and applies whatever it receives. The unprotected configuration is the one reachable by the more convenient path, and the protected one requires knowing to write a file.

Running unverified is a deliberate, supported mode: a witness with no signing identity of its own is a legitimate deployment, and refusing to start would break existing installations that predate the authenticated channel. The problem is not that the mode exists. It is that the mode is entered by omission rather than by choice, and that the omission is easiest to make from the interface most likely to be used.

A startup warning is emitted when a witness is configured to follow an authority without an expected identity. It is written directly to standard error rather than through the logging layer, deliberately, because it runs before logging is initialised and so cannot be suppressed by log configuration. That warning is therefore the only thing standing between a command-line deployment and silent acceptance of unverified state — which makes it load-bearing rather than informational, a heavier role than a warning should carry.

## Two further gaps in the same area

The warning is emitted during configuration resolution. Any embedder that constructs the server configuration directly, as a library, never passes through that path and so never sees it.

The asymmetry is itself the clearest signal of the defect: two settings that must be supplied together to get a working authenticated channel are reachable through different mechanisms, and nothing checks that the pair is coherent.

## Resolving this

Give the expected-identity setting the same command-line and environment surface the authority address already has, so that both halves of the authenticated channel are configurable through any one interface.

Separately, consider whether a witness told to follow an authority without being told whom to trust should be a hard startup failure with an explicit opt-out flag, rather than a warning. That converts entering the unverified mode from an omission into a decision, without removing the mode. It is a compatibility question rather than a technical one, and it should be decided deliberately.

Related: #141.

Start by tracing configuration resolution and how the existing authority-address setting is exposed through command-line and environment inputs. Check the related tests and use them to identify how to verify that the expected identity can be supplied through both interfaces. The concrete change is done when both channel settings are configurable through the same interfaces; the separate warning-versus-hard-failure policy remains a compatibility decision.

Written by the indexing model from the issue text.