fix(engines): require scapy>=2.6.0 in the Scapy and dev extras (#1572)

[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• Searched for similar pull requests

• Followed the coding style (make pylint, make mypy, make isort)

• make test passes, and a test case covers the change

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

Closes #1572.

• Fix: Scapy and dev now require "scapy>=2.6.0; python_version >= '3.7'", and the Pipfile [dev-packages] entry has the same floor and marker. 2.6.0 is the first release after 2.5.0 and fixes all three failures in the issue. The marker works like PCAP_CT's: 2.6.0 declares Requires-Python >=3.7.
• Measured on main (cc084357f, fix(engines): take a scapy packet's link type and clock from its interface (#1503, #1517, #1549) #1563 included): toolkit, trace and engine-agreement selections give 4 failed on scapy 2.5.0 and 22 passed on 2.6.0. 2.6.0 installs and imports on 3.10–3.14. A pip install --dry-run of the new requirement, run over an existing 2.5.0 install, upgrades it to 2.8.0.
• Docs: the engine-prerequisites note in docs/source/index.rst states the floor, and that pcapkit does not check the version at run time.
• Tests: a new DependencyRequirementTests method pins both requirement strings. On main it fails with ['scapy'] != ["scapy>=2.6.0; python_version >= '3.7'"]. Its dev half fails by itself too.
• Not changed: conda/requirements.txt and examples/benchmark/requirements-common.txt already pin scapy==2.8.0. There is no Pipfile.lock, and no test reads the Pipfile. CI installs through the extras.

[JarryShaw]

Verdict: GOOD TO GO at ef436c04e. Cross-reviewed on Sonnet; the author ran Opus. It merges cleanly into current main.

• The floor is right. On origin/main, scapy 2.5.0 fails all three: KeyError: 0 in test_dns_records_are_converted, trace hash b2a5ea79… against 7679cddf…, and profile.pcapng timestamps 1500000000.0005 != 1500000.0000005. Scapy 2.6.0, the next release, passes them, and its scapy CI selection gives 68 passed.
• The requirement strings work. Both extras reject 2.4.5 and 2.5.0, accept 2.6.0–2.8.0, and their marker is false on 3.6 but true on 3.7 and 3.10–3.14. pip install --dry-run '.[Scapy]' resolves 2.8.0, even in a venv already holding 2.5.0. pipenv 2026.8.0 parses the Pipfile entry as the same requirement.
• Nothing is missed. conda/requirements.txt and examples/benchmark/ pin 2.8.0. The workflows install through the extra. Nothing else in the repo admits 2.5.0.
• Fail-before: with main's pyproject.toml, the new test fails ['scapy'] != [...].
• Tests: tests/test_tier_guard.py (110), the two doc-claims modules and test_isort_clean.py all pass.

Non-blocking nits:

• The comment at pyproject.toml:146 says the marker matches PCAP_CT's, but PCAP_CT's is >= '3.10'. Only the mechanism is shared, and the test docstring repeats the slip.
• The docs note names only the timestamp failure. It doesn't mention the DNS shape or key-order differences.