Version 0.3.0

v0.3.0 — Fiber-optic (G3CL loop) and echo-enabled link support

The headline: the SDK now works over a fiber-optic/FTR link, where the Group3
Communication Loop retransmits every command back to the host before its reply
(manual §4.5.1, p.4-7). Previously the first reply read back was your own
command, surfacing as an opaque parser error. Verified end to end against a
DTM-151-S on an FTR optical link.

Added

• Automatic detection of returned commands. DTM151Serial.identify() probes
  for them at connect time and configures the protocol; detect_command_echo()
  exposes the probe alone. DeviceProfile gained command_returned and
  loop_echo, which distinguishes a G3CL loop (topology — SE0 cannot stop it)
  from DIP S2-4 echo (a setting).
• Self-explaining diagnostic. A reply identical to the command just sent now
  raises a ProtocolError naming both possible causes and the fix, instead of
  failing two layers away in the parser.
• Double-returned commands (S2-4 echo over a G3CL loop, manual §3.6
  p.3-11) are handled — every returned copy is stripped, whether the copies
  share a frame or split across frames.
• Group3Protocol.send_unvalidated() — an explicit escape hatch for repair
  paths: write, drain, finalise, no validation.
• --echo {auto,on,off} on all seven examples, defaulting to auto.

Fixed

• SM1 streaming on a returning link. SM1 is issued write-only, so its
  returned copy stayed on the wire and the first streaming read parsed it as a
  reading (Expected numeric field reply, got 'SM1'). Cleared before streaming
  begins, at both stream entry and paused() resume. Request/reply paths were
  never affected — request() resets the input buffer first; a streaming read
  cannot.
• identify() no longer trusts the SE0 ack. It re-probes afterwards,
  because SE0 turns off device echo but cannot stop a loop. It also sends
  SE0 tolerantly: on real hardware, echo-over-loop corrupts the echoed ASCII
  copy (F came back as |), and a strict check aborted the one command that
  repairs the link.

Changed (non-breaking)

• Group3Protocol.echo_enabled → expect_command_returned;
  DeviceProfile.echo_enabled → command_returned. The old name conflated
  a device setting with a wire topology, which is what caused the SE0 bug.
  Both old names still work as deprecated aliases — attribute and constructor
  — and emit DeprecationWarning. DipSwitches.echo_enabled is unchanged; it
  really is the S2-4 bit.
• Examples call identify() rather than the bare probe, so a link that needs
  repair gets it. On an echoing device this now sends SE0 — the only
  device-state change, and only when commands are being returned.
• README documents identify() as the connect-time call, and the multi-drop
  snippet declares expect_command_returned=True (a G3CL is a loop by
  construction; don't probe there — the probes are unaddressed).

Migration

None required. If you construct Group3Protocol or DeviceProfile with
echo_enabled=, switch to the new names to silence the warning. Add
dtm.identify() after connect if you don't already call it — required on
fiber-optic/G3CL links, harmless elsewhere.

Known limitations

• --echo on does not repair. It declares a returning link without probing,
  so on the loop + S2-4-echo configuration it fails. Documented in the flag's
  help; auto is the safe default.
• Multi-drop is unverified against hardware. The
  expect_command_returned=True guidance for G3CLSession follows from the
  manual and FakeTransport coverage, but needs two units on a loop to confirm.

Tests

261 → 300, including golden transcripts for loop ripple, double returns,
corrupted-echo recovery, and a smoke suite that drives the examples end to end
against a simulated loop device.

What's Changed

• Updated to support auto detect of G3 loop and/or echo set on. by @tobyerbailey in #5

Full Changelog: v0.2.1...v0.3.0