tests: pin ipv6-route Source Route tuple/list address packing

[JarryShaw]

Summary

• schema: let ListField.pack accept the tuple its own data models declare #480 fixed Schema.pack's ListField branch to accept a tuple as well as a list (see schema: Schema.pack rejects the tuple its own data models declare, breaking parse-then-reconstruct for 16 HIP parameters #476), but the one consumer that ships a tuple[...]-typed field against that branch landed on main with no test of its own: SourceRoute.ip in pcapkit/protocols/data/internet/ipv6_route.py (tuple[IPv6Address, ...]) is backed by the ListField in SourceRoute in pcapkit/protocols/schema/internet/ipv6_route.py. Before schema: let ListField.pack accept the tuple its own data models declare #480, building a Type 0 (deprecated Source Route) routing header through IPv6_Route.make with a tuple of source addresses raised ProtocolUnbound; the same call with a list succeeded.
• Adds test_ipv6_route_source_route_make_accepts_tuple_and_list_addresses to tests/protocols/internet/test_ipv6_extension_unit.py, exercising IPv6_Route.make → Schema.pack (the public construction path ipv6_route.py actually uses) rather than building Schema_SourceRoute directly. It covers zero, one, and two addresses as both a tuple and a list, asserts the two forms pack byte-identical output (the real invariant schema: let ListField.pack accept the tuple its own data models declare #480 established), and round-trips the packed bytes back through Schema_SourceRoute.unpack to confirm the addresses come back in the same order.
• I verified the test actually catches the regression: temporarily narrowing the ListField branch in pcapkit/protocols/schema/schema.py back to isinstance(data, list) makes all three subtests fail with pcapkit.utilities.exceptions.ProtocolUnbound: unsupported type <class 'tuple'>; restoring the file via git checkout -- brings it back to green. No source under pcapkit/ is changed by this PR.

A separate, pre-existing issue found (not fixed here)

While building the round trip, I found that a full IPv6_Route read of a Source-Route header (_read_data_type_src's (header.length - 8) % 16 check) rejects every length that IPv6_Route.make itself computes for this routing type, for any address count and regardless of tuple vs. list — e.g. make computes length=20 for a single address, and _read_data_type_src requires (length - 8) % 16 == 0, which no non-negative length of the form 4 + 16*n ever satisfies. The same category of mismatch shows up in _read_data_type_2 (header.length != 24) for the analogous Type2 routing data. This looks unrelated to #476/#480 and I have not touched it; the new test avoids it by round-tripping through Schema_SourceRoute.unpack directly instead of a full IPv6_Route read.

Test plan

• PYTHONPATH=<worktree> .venv/bin/python -m pytest tests/protocols/schema/ — 25 passed
• PYTHONPATH=<worktree> .venv/bin/python -m pytest tests/protocols/internet/test_ipv6_extension_unit.py — 50 passed, 74 subtests
• Reverted the ListField fix locally, confirmed the new test fails with the pre-fix ProtocolUnbound error, then restored the file with git checkout -- and confirmed the test passes again

[JarryShaw]

Landed directly on main as part of 8e6ffc806, per the repo owner's standing allowance that test-only changes may be pushed straight to main rather than going through a PR.

Closing by hand because GitHub does not mark a PR merged when its commits arrive via a push rather than the merge button, even though they are genuinely on main — verified with git merge-base --is-ancestor <branch> origin/main, which passes for this branch.

Before pushing I confirmed the change really is test-only and that it passes, rather than taking the branch's word for it:

git diff --name-only fcd853032..HEAD | grep -v '^tests/' | wc -l   ->  0

tests/foundation/reassembly/test_ip.py + tests/protocols/internet/test_ipv6_extension_unit.py
    66 passed, 80 subtests passed

tests/foundation/reassembly/ + tests/protocols/internet/
    248 passed, 645 subtests passed   (exit 0)

main went fcd853032 → 8e6ffc806, carrying both test-only branches in one push: the ipv6-route tuple/list packing test and the two IP conflict coverage gaps from #482's review.