feat(leveva): IRCv3 labeled-response (+ batch dependency) (P11 slice 155)
Echo a command's inbound `@label` tag back on its direct reply so a client
can correlate request->reply across interleaved output. The pure
`leveva::labeled::wrap` runs over the `command::dispatch` reply vector at the
session seam and renders the spec's three shapes: 0 replies -> `@label ACK`,
1 -> the lone reply tagged in place, >=2 -> a `labeled-response` BATCH
(`+<ref>` open carrying the label, `@batch=<ref>` inners, `-<ref>` close).
The batch ref is a process-global hex counter (the msgid precedent),
generated by the caller so `wrap` stays pure (the fuzz target).
Advertise both `labeled-response` and `batch` (the wire dependency); the
wrap gate is `labeled_response` only, `batch` is wired-but-not-read (a future
dedicated batch slice adds other batch types). New Message::with_label /
with_batch front-prepend helpers.
Scope: the synchronous direct-reply path only. Async mailbox lines
(echo-message, channel fan-out) travel a different path and are not in a
labeled batch -- a labeled PRIVMSG yields ACK (its echo, if negotiated,
arrives separately untagged), which satisfies the spec's self-message
MUST-NOT-label rule conservatively. leveva-native (the oracle predates CAP).
Tests: labeled/message/cap units + labeled_response_proptest (600 cases over
pure wrap) + golden_labeled_response (real binary: WHOIS-batch / TIME-single /
PRIVMSG-ACK / non-negotiating inverse) + a batch=<REF> canonicalizer mask.
The real ircv3.net spec lives at docs/rfcs/ircv3/labeled-response.md.
Gate: cargo test -p leveva green (229 binaries, 0 fail), clippy clean,
cargo build --workspace 0 warnings.