docs(release): document #4366 and #4368 for the 4.13.2 notes

[Yeraze]

Two changes ship in 4.13.2 but are missing from its notes. This closes both before the tag.

Why they were missed

• feat(meshcore): serve ExportPrivateKey over the Virtual Node behind an "Allow PKI export" gate #4366 (MeshCore VN PKI export) merged into main while the release PR chore(release): 4.13.2 — version bump, changelog backfill, doc gaps #4367 sat in a stuck GitHub merge lock, so it landed after the changelog was written.
• fix(meshtastic): only push add_contact when the radio lacks the peer's key (#4368) #4369 is queued to merge before the tag at your request.

Either way both are in the v4.13.2 tree, so both need entries — this is the same drift the release PR just cleaned up, and it should not be reintroduced on the way out the door.

#4366 — Virtual Node "Allow PKI export"

CHANGELOG entry, a blog item, and the feature docs it shipped without: a new PKI private-key export (MeshCore) section in docs/configuration/virtual-node.md.

The docs lead with the three things that matter before enabling it:

• the Virtual Node port has no client authentication
• the private key is a strictly larger grant than admin commands — admin commands change the node, the key lets a client permanently become it, which is exactly why it is a separate switch and never implied by allowAdminCommands
• with the gate off the VN replies Disabled, byte-identical to firmware built without ENABLE_PRIVATE_KEY_EXPORT, so clients show an accurate "unavailable" instead of hanging

#4368 — add_contact re-favoriting every DM recipient

A one-line "Fixed" entry undersells this one, so the blog gets a short section of its own. It explains a symptom users actually saw and misattributed to the zero-hop auto-favorite feature: MeshMonitor pushed add_contact before every PKI DM, and the firmware's addFromContact() sets is_favorite = true to shield the entry from NodeDB eviction — so every DM, including every Auto-Ack reply, re-favorited its recipient.

The entry is explicit that the isFavorite downsync is untouched and that key-push still happens whenever the radio genuinely lacks the key, so nobody reads this as "PKI DMs got weaker".

Merge order

This must merge after #4369, since it documents that fix. Then the tag.

Verification

Docs-only — no code, no version change. docs:news regenerates cleanly with the new blog content.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PZtasD4tS76xq2PTDHMA5o

[github-actions]

Claude finished @Yeraze's task —— View job

---

PR Review — docs(release): document #4366 and #4368 for the 4.13.2 notes

• Read changed files
• Review CHANGELOG.md changes
• Review blog post changes
• Review virtual-node.md documentation
• Post final review

---

This is a docs-only PR adding CHANGELOG entries and documentation for two features that shipped in 4.13.2. The writing is clear and the security messaging is appropriately direct. A few observations:

docs/configuration/virtual-node.md

Minor issue — step numbering inconsistency across sections:

The Meshtastic VN setup steps (lines 75–81) were updated to add step 6 for MeshCore PKI export and push "Click Save" to step 7. However, the MeshCore Virtual Node setup section starting at line 459 is a separate set of steps and still ends at step 6 (no PKI export step there). That's actually correct — the MeshCore VN section doesn't repeat the PKI export step — but the PKI export step in the Meshtastic VN section (step 6) is slightly odd placement: the Meshtastic VN section describes setting up a meshtastic_tcp source, but allowPkiExport only applies to MeshCore sources. A reader going through the Meshtastic TCP setup steps will hit step 6 which says "On a MeshCore source..." — the conditional language handles it, but it reads as a non sequitur in a section otherwise entirely about meshtastic_tcp.

Consider: either moving step 6 to the MeshCore VN setup steps only, or adding a brief note to the MeshCore VN setup steps at line 459–466 that also references the PKI export option, since that's where users setting up a MeshCore source would land.

Minor: ExportPrivateKey(23) vs Disabled(15)

The docs use ExportPrivateKey(23) and Disabled(15) with numeric codes. These match the CHANGELOG. Fine for technical accuracy; just worth confirming those command/response codes are stable (not enum ordinals that could shift across firmware versions).

allowPkiExport: false in the JSON example

The JSON block shows the default (false). This is a good pattern — shows users exactly what they'd add, and the default makes the gate visible in the config even when it's off. No issue.

"The Info tab shows a PKI Export row" (line 131)

Useful callout. Confirmed this is accurate per #4366.

CHANGELOG.md

The PKI export entry is thorough and appropriately explains the separation from allowAdminCommands. The add_contact re-favoriting entry is similarly detailed and explicitly addresses the "isFavorite downsync is untouched" concern. Both entries are appropriately scoped to what changed and what didn't.

One very minor nit: The PKI export entry references (#3933, #4366) — #3933 is presumably the original tracking issue. Just confirming that's intentional and not a stale issue number copy-paste.

docs/blog/2026-07-27-v4.13.2-release.md

Both new sections are well written and appropriately pitched for a general audience. The PKI export section correctly leads with the trust model ("the port has no client authentication") and the "separate switch" rationale. The add_contact section correctly notes "Nothing about how favorites sync back has changed" — good to have that explicit.

The new blog sections slot in cleanly with the surrounding content.

---

Summary: The documentation is accurate, clearly written, and the security warnings are appropriately prominent. The only structural observation worth considering is whether the PKI export setup step belongs in the Meshtastic VN section or only in the MeshCore VN section — since allowPkiExport is MeshCore-only and a reader following the Meshtastic TCP steps might be confused by it appearing there. Otherwise this is ready.