Read one line of VERSION_CODENAME from os-release

[jetm]

Problem

Every dnf call inside the SDK fails when AVOCADO_SDK_REPO_RELEASE is unset,
which is the default path. The generated entrypoint reads the release codename
from /etc/os-release with an unanchored grep, and os-release is a key=value
file rather than a map: nothing stops a key repeating, and both published SDK
images repeat this one. Measured 2026-09-04, avocadolinux/sdk:2024-edge and
:2026-edge each carry two identical VERSION_CODENAME lines.

REPO_RELEASE is then two lines, so dnf --releasever=$REPO_RELEASE hands dnf
the second line where it expects a subcommand and it exits with
No such command: 2024/edge.

Solution

Bound the read to the first match, so the reader is correct against any
os-release rather than against the two images whose contents happen to be known
today.

Key changes

• Anchor both emission sites of the os-release read with head -1.
• Add an executing test that lifts the pipeline out of this file and runs it against a fixture with a duplicated key. An inlined copy of the pipeline would pass against a fix that never shipped.
• Add a second test counting the emission sites, because the two copies are edited independently and reverting either one alone is a regression the executing test cannot see: it reads whichever site it finds first.

Reviewer notes

What made this expensive to find is where it surfaces, and that part is not
fixed here. The kernel resolver routes both of its repoqueries through
2>/dev/null || true, so a dnf that never ran looks exactly like a dnf that ran
and matched nothing. The operator sees
no kernel versions found in the repository to choose from against a repository
that has them, with the real error discarded two layers down. That swallowing is
worth a separate look; this change only stops one cause of it.

Also not fixed here: the images should stop shipping the key twice. This
makes the reader correct regardless, which is the layer reachable from this repo.

Feedback I am after: whether head -1 is the right anchor versus taking the
last match, and whether the site-counting test earns its keep or is too clever.
I chose first-match because a repeated key with differing values is already
broken and the first is what a shell source of os-release would leave set.