Turn the remaining display strings into typed values

[EONRaider]

Target: 2.1.0 (Tier 3 — make typing the product)

The 1.3.0 option work landed the hard part — TCP.parsed_options
returns tuple[TCPOption, ...] and TCPOption.value decodes MSS,
window scale, SACK and timestamps into real types. Four places still
stop at a display string or raw bytes:

1. DNS RDATA is a rendered string. DNSResourceRecord.rdata_text
handles A, AAAA, NS/CNAME/PTR, MX, TXT and SOA, then falls back to
rdata.hex() — but it returns str for all of them. An A record
should give an ipaddress.IPv4Address, TXT a list[str], SOA a
structured record. Related: only the first question is exposed
(question_name/question_type/question_class); there is no
questions tuple.

2. DHCP has no option type. DHCP.option_map returns
dict[int, bytes] — the only accessor in the library that returns a
bare dict rather than typed objects. There is no DHCPOption class.
Only option 53 is interpreted, via message_type.

3. IPv4 options are named but not decoded. IPv4Option has
kind_name and no value. Record Route (7), Timestamp (68) and
Router Alert (148) are named, and their contents left raw — unlike
TCPOption, which does decode its values.

4. IPv6Routing.data is entirely unparsed. No segment-list
extraction for RH0, RPL or Mobile IPv6. IPv6Option likewise decodes
no values (Router Alert, Jumbo Payload stay raw).

Note on scope

This is four independent pieces of work sharing one theme. Split into
separate PRs — probably one per numbered item — rather than one large
change. DNS (1) is the highest value; IPv6 Routing (4) the lowest.

Whatever is added must not break bytes(decode(x)) == x: the raw bytes
stay authoritative, and typed values are derived lazily from them, as
parsed_options already does.

Acceptance criteria

• DNS exposes structured RDATA and a full questions tuple.
• A DHCPOption type replaces the bare dict, or the dict is
  documented as deliberate.
• IPv4Option.value decodes the three named kinds.
• Round-trip guarantees unchanged throughout.

[EONRaider]

All four independent pieces landed, each in its own PR as this issue's own text instructed:

1. DNS (highest value) — DNS: typed RDATA values and every question, not just the first #136: DNSResourceRecord.rdata_value (typed RDATA — IPv4Address/IPv6Address/MXRecord/SOARecord/list[str], rdata_text unchanged) and DNS.questions -> tuple[DNSQuestion, ...] (every question, not just the first).
2. DHCP — DHCP: add a typed DHCPOption alongside option_map #137: a DHCPOption type (mirroring TCPOption), exposed via DHCP.parsed_options, alongside the unchanged option_map.
3. IPv4Option — IPv4Option: decode Record Route, Timestamp and Router Alert values #138: .value decodes Record Route, Timestamp, and Router Alert (RFC 791 §3.1, RFC 2113).
4. IPv6 Routing (lowest value, explicitly callable-out-as-skippable — landed anyway) — IPv6: decode Routing header segments and Router Alert/Jumbo Payload #139: IPv6Routing.segments decodes RH0/Mobile IPv6 address lists; RPL is deliberately left undecoded (its compression needs the enclosing packet's destination address, context a single extension header doesn't have). IPv6Option.value decodes Router Alert and Jumbo Payload.

Every piece is additive — no breaking changes, no retyped wire fields (per #105's stated non-goal), every new accessor degrades to None/documented default rather than raising. Full QA ladder green on all four merges.

---

Generated by Claude Code