Reconcile TC18 module naming with RELAY spec v1.14 §13.7.2 #45

RELAY spec v1.14 (https://github.com/SoundMatt/RELAY/releases/tag/v1.14.0) expanded §13.7.2's standard module-name registry with canonical names for the RCP protocol-core concerns this repo's TC18 replacement is building. This was prompted by comparing all four go/cpp/rust/c-RCP replacement efforts directly and finding real naming drift for the same concepts — filing this on each repo so naming converges going forward, per §13.7's requirement that "the names are identical across languages."

Deltas found in this repo (as of the comparison)

1. wire.hpp (new) / legacy_wire.hpp (old) → rename to avtp.hpp. The registry names the AVTPDU header-framing layer avtp (matching go-RCP's and c-RCP's naming). This repo reused the old wire.hpp name for the new format and renamed the old implementation to legacy_wire.hpp — the inverse naming strategy from the other three. Recommend avtp.hpp for the new AVTPDU/NTSCF/TSCF framing, and whatever name fits for the retired old-protocol code (or removal, if the old wire format is no longer needed once cutover happens).

2. Verify acf is separated out. If wire.hpp/legacy_wire.hpp currently bundles ACF_ABB/ACF_GBB message-format handling (byte_message_info, request/response/ack encoding) together with AVTPDU header framing, split it into a separate acf.hpp per the registry — rust-RCP and c-RCP already have this split.

3. lifecycle.hpp, regmap.hpp, discovery.hpp — already correctly named and already match the registry (this repo, rust-RCP, and c-RCP all independently split these three apart; go-RCP is the outlier still consolidating them into one server package). No action needed here — this repo is actually the reference case for this part.

4. e2e.hpp — already correctly named. No action needed.

5. No dedicated request.hpp module visible. The registry's request entry covers the conditional-request taxonomy (compound/compound-wait/triggered/chained/timed) plus sequencers. sequencer.hpp exists as its own file, but the conditional-request-kind logic doesn't appear to have its own top-level header. Worth checking where this logic currently lives and whether it should be consolidated under (or re-exported from) a request module, even if sequencer.hpp stays as an internal implementation file within it.

6. No dedicated fragment.hpp module visible. If AVTPDU/ACF fragmentation logic exists elsewhere (e.g. folded into wire.hpp), consider extracting it to match the registry's fragment entry — go-RCP already has this as its own package.

Secondary note (not a naming issue, flagging for cross-repo awareness)

This repo's roadmap explicitly calls for DEPRECATE on canbr.hpp/linbr.hpp ("CAN and LIN native endpoint types of an RC Server... rather than something external to bridge to from an RCP Client"), while go-RCP's roadmap keeps them as ADAPT (bridging concept survives in reduced scope, as an ergonomics layer). Both are reasoned positions — but worth a conscious cross-repo decision on which one all four implementations should converge on, since it's a real behavioral difference, not just naming.

Not asking for a specific PR — just flagging accurately so whoever/whatever picks this up (including a future pass of the ongoing build-out loop) can verify these deltas against the actual current code and fix what's confirmed.