Pin the packages images/platformio installs, or drop the ones nothing uses

[hacker-cb]

images/platformio/Dockerfile installs three packages without an exact version.
#19 pinned the esp-idf harness
and added ./scripts/check-pins.sh as a lint gate, but exempted these three with
# pin-allow: comments rather than pinning them, because each needs a decision
that does not belong in an esp-idf change. This issue is that decision.

The exemptions are not silent: the gate fails on an allowance that covers nothing,
so removing a package here without removing its pin-allow breaks the build, and
adding a fourth unpinned package is still caught.

1. protobuf and jinja2 — the question is "keep", not "which version"

images/platformio/Dockerfile:47-48, installed since the initial commit:

RUN pip install --no-cache-dir \
    platformio==${PIO_VERSION} \
    protobuf \
    jinja2

Neither has a consumer in the image:

• platformio 6.1.18's own requires_dist names neither (it pulls bottle, click,
  colorama, marshmallow, pyelftools, pyserial, requests, semantic_version, tabulate,
  ajsonrpc, starlette, uvicorn, wsproto);
• platform-espressif32 6.11.0 installs its own Python dependencies in
  builder/frameworks/espidf.py — urllib3, cryptography, pyparsing,
  idf-component-manager, esp-idf-kconfig — and names neither;
• nothing in images/platformio/pio_project/ imports either;
• the only other mention in this repository is images/platformio/README.md:26-27,
  which offers them as capabilities of the image ("Protocol buffer support",
  "Template engine") — that is, for the user's own scripts.

So pinning them first would freeze something that may simply want removing. If they
stay, the two want different treatments:

• protobuf — three supported major lines run in parallel (5.x, 6.x, 7.x) and
  the major moves about once a year; an unpinned install picks one by build date.
  Espressif's own constraints still cap it at protobuf<=3.20.1 for esp_prov
  (AttributeError: 'NoneType' object has no attribute 'message_types_by_name' protocolbuffers/protobuf#10075, unresolved since 2022), which is the strongest
  available argument against letting it drift here.
• jinja2 — the opposite case: no release in the last year, and 3.1.3 through
  3.1.6 were all security patches. A hard == would freeze the image on the next
  CVE, so a floor-and-ceiling (>=3.1.6,<4) fits it better than a pin. Note that
  check-pins.sh gates on == today, so a range needs its pin-allow to stay,
  with the reason rewritten to say why a range rather than why later.

2. Unity — a range that has already diverged

images/platformio/Dockerfile:66, with ARG UNITY_VERSION=2.6.0 at line 9:

RUN pio pkg install -g --library "throwtheswitch/Unity@^${UNITY_VERSION}"

@^ is a semver range (>=2.6.0 <3.0.0), not a pin — and the published image
carries Unity 2.6.1 while the ARG says 2.6.0. images/versions.json's _readme
calls that Dockerfile default "the only source of truth" for UNITY_VERSION, which
it is not while the caret is there.

Dropping the caret changes what the image contains, so it must land together with a
bump of ARG UNITY_VERSION to whatever version is actually wanted. Bumping to
2.6.1 in the same change keeps the image byte-identical and makes the number
stop lying; moving to 2.7.0 (released since) is a separate decision about upgrading
Unity, and should be taken as one.

Trigger

None pending — this is ready to pick up. It is deferred by scope, not by a
dependency.

Source

• images/platformio/Dockerfile:41-48 and :60-66 (the three pin-allow comments)
• #19, which introduced the gate and the exemptions
• #18, the esp-idf half of the same problem