fix(dumpkit): escape mapping keys for the plist writer (#772)

[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 — changelog 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
• chore — anything else

---

Description of your pull request and other information

The in-repo half of #772. #771 escaped every dumped value for the plist writer, but
_append_dict interpolates a key into '<key>{item}</key>' and only calls _encode_value on
the value, so object_hook never sees a key. Both branches that build a mapping now escape their
own keys through one escape_key helper — a MultiDict, where #771 escaped an enum-derived key
inline and nothing else, and a plain dict, where nothing was escaped.

Non-str keys are rendered with format, not skipped, and not str-ed arbitrarily. format(key, '')
is the conversion '{item}'.format(item=key) already applies, so the <key> text is unchanged
apart from the escaping. It has to be handled: test.pcapng's decryption secrets block keys its TLS
key log entries by a raw bytes client random whose repr carries &, < and > — and that key
reaches the writer through an OrderedMultiDict, so fixing only the plain-dict branch would not
have fixed the fixture.

test.pcapng before: ET.parse fails, not well-formed (invalid token): line 1517, column 19.
After: parses. Measured over 6 captures × 5 formats on fe80b8525: 2 of the 30 reports changed
(that capture's plist and xml, which are one writer under two names), by exactly one line;
the other 28 — every json, tree and text report included — are byte-identical. Nothing
double-escapes: no < anywhere.

pcapkit/dumpkit/common.py stays at 100% coverage over tests/dumpkit/ (84 → 88 statements,
38 → 40 branches, no new misses). The upstream half is JarryShaw/DictDumper#125, which would make
this workaround redundant; this does not wait on it.

Closes #772 — the pcapkit-side half. The upstream _encode_value-on-keys change stays
tracked at JarryShaw/DictDumper#125, in that repo, and is not a hold on this board.

[JarryShaw]

Cross-review at 9bec70e22 (sonnet, a different model from the author): GOOD TO GO, no required changes. Every number in the body reproduced independently, and the merge was checked rather than assumed.

The corrected diagnosis is confirmed at source. dictdumper/plist.py writes '{tabs}<key>{item}</key>\n'.format(tabs=tabs, item=item) then file.write(keys), calling _encode_value only on the value — never the key. And the OrderedMultiDict key really is bytes.fromhex(random) from TLSKeyLog.post_process (pcapkit/protocols/schema/misc/pcapng.py:1975-1985), so it is raw bytes reaching the MultiDict branch, not a plain-dict key. That is the thing my original #772 comment got wrong and you corrected.

The format() over str() choice is right, not over-careful — and the reviewer proved it rather than agreeing with it. Probed a key whose __format__ differs from __str__: format(k, '') equals the writer's own '{item}'.format(item=k) while str(k) diverges. Also checked an int key and a str-subclassing Enum key, both matching. So the equivalence the design rests on holds across the key types that can actually occur.

2 of 30, re-derived from its own fixtures. It generated captures itself and dumped 6 pcapng captures × 5 formats on fe80b8525 versus the head: exactly 2 changed (test.pcapng.plist and .xml), each by exactly one line (1517c1517), the other 28 byte-identical, and zero < / > / & anywhere. ET.parse on the base fails at not well-formed (invalid token): line 1517, column 19, in a report of 1958 lines. Its capture set was chosen independently and still reproduces your counts exactly.

Double-escaping ruled out structurally, not just by test: the old inline escape(key) at the enum branch is gone from the diff, replaced by the single escape_key() that gates on escape_strings itself. Identity preservation confirmed — assertIs holds and nothing rebuilds on the non-escape path. Coverage matched at 84→88 statements and 38→40 branches, 100% with zero misses, cross-checked under plain unittest at 14 + 4.

Merge into current main (0419c1c97) done by the reviewer itself: clean, and on the merge result tests/dumpkit/ gives 24 passed / 71 subtests with the same 88/40 coverage, plus tests/test_tier_guard.py and tests/project/test_isort_clean.py green to rule out interaction with #782's tier-guard changes.

Two incidental findings, neither blocking. The stale skip reason at tests/integration/test_pcapng_end_to_end.py:185 is confirmed — and it is internally inconsistent even before this PR, citing line 1376 where the measured failure is 1517. Its plist half dies with this change; its json half survives. Correctly left untouched, and I am filing it separately. Second: a pre-existing isort ordering quirk in tests/dumpkit/test_common_unit.py's import block, identical on the base. That is not a gap in the isort test — the Makefile isort: target covers pcapkit, pcapkit/const, pcapkit/vendor, util/*.py and examples/generators/*.py, and tests/ is deliberately outside its scope. Nothing to chase.

CI fully green: 27 success, 3 expected skips.