fix(engines): dpkt on a nanosecond PCAP and scapy truncate the timestamp under a low decimal precision #1689

Describe the bug
At a decimal precision below about 16 digits, dpkt on a nanosecond PCAP and scapy on PCAP and PCAP-NG hand reassembly and the tracer a truncated timestamp. The default engine wraps the same arithmetic in localcontext(prec=64) (pcapkit/protocols/misc/pcap/frame.py:263, pcapkit/protocols/misc/pcapng.py:1810), so it is unaffected. The precision is the caller's: decimal.getcontext().prec = 12 set anywhere in the process is enough.

• dpkt, ns PCAP: pcapkit/foundation/engines/dpkt.py:292, value = hdr.tv_sec + (hdr.tv_usec / self._divisor) with a Decimal divisor. It copies dpkt/pcap.py:399, which the _upstream fallback reaches.
• scapy: pcapkit runs scapy's readers in the caller's context. PCAP: scapy/utils.py:1586 (2.7.0; :1631 in 2.8.0), EDecimal(pkt_info.sec + power * pkt_info.usec). PCAP-NG: :2072 (:2141), EDecimal((tshigh << 32) + tslow) / tsresol.
• Probably also pcapkit/foundation/engines/scapy.py:217, packet.time += self._offset, for a PCAP-NG if_tsoffset. This was checked only as an expression: 1500000000.123456 + 1 at prec 12 gives 1500000001.12.
• Unaffected: default; dpkt on µs PCAP (float arithmetic) and on PCAP-NG (engines/dpkt.py:181); pypcapfile (integer division). pyshark was not measured.

Reproduction
main at f20d0a600; Linux, CPython 3.14.8, dpkt 1.9.8, scapy 2.7.0. Each capture holds one Ethernet/IPv4/TCP frame at ts_sec=1500000000, with frac 123456 µs or 123456789 ns. Each is extracted with trace=True inside decimal.localcontext() at the given prec. In every cell the IPv4 reassembly input, the trace input and the trace file name (…_9-<ts>.json) agree with each other.

At prec 28 every engine agrees. Found while reviewing the #1668 fix, which wraps dpkt's µs exact (engines/dpkt.py:296) in localcontext(prec=64) for the same reason.

Expected behavior
At any ambient precision, every engine hands over the default engine's value. One approach: compute dpkt's ns timestamp under localcontext(prec=64), and run scapy's readers and the if_tsoffset addition under one too. A stored dpkt frame's value would then change only where it was truncated before.