Bring up the OP-TEE fTPM on imx93-frdm

[jetm]

Problem

The i.MX93 FRDM board has no discrete TPM, and the EdgeLock Secure Enclave is
not one either - it speaks an NXP-proprietary interface, not the TPM2 command
set that systemd-cryptenroll and cryptsetup --token need. So the TPM2 path
the /var encryption stack already implements (PCR-7 seal on first boot,
--token-only open thereafter) had nothing to bind to on this machine, and
/var fell back to its Argon2id keyslot every boot.

The OP-TEE fTPM is the viable route: the board already enables OP-TEE
unconditionally, has eMMC 5.1 with RPMB, and carries a recovery partition for
the TEE store. What was missing was the wiring.

Solution

Add the fTPM as an opt-in kas feature rather than a machine default, because
turning it on pulls two layers into the build and that must not happen to a
board that did not ask for a TPM.

optee-ftpm-init moves from meta-avocado-qemu into the shared meta-avocado
layer. An i.MX93 build never parses the qemu layer - its machine config pulls
base, nxp and freescale only - while the initramfs packagegroup that installs
the recipe is shared, so leaving it in place would have meant an RDEPENDS with
no provider.

The TA itself comes from meta-arm, which carries both halves: optee-ftpm
builds the Microsoft TA, and its optee-os_%.bbappend folds it into BL32 via
CFG_EARLY_TA.

Key changes

• New kas/feature/ftpm.yml: appends optee-ftpm to MACHINE_FEATURES, pulls
  in meta-arm for the TA and meta-security's meta-tpm for tpm2-tss.
• optee-ftpm-init relocated to meta-avocado/recipes-security/, with
  COMPATIBLE_MACHINE widened to cover avocado-imx93-frdm.
• New ftpm.cfg kernel fragment: the driver as a module (its NV storage is
  REE-FS, serviced from userspace, so it cannot probe at kernel init), and
  CONFIG_HW_RANDOM_TPM left unset so the hwrng kthread cannot hold
  tpm_mutex across a GetRandom loop and starve the PCR-7 seal.
• optee-ftpm_%.bbappend under meta-avocado-nxp/dynamic-layers/meta-arm.
• AVOCADO_SECURITY_CAPABILITIES on imx93-frdm extended to
  encrypted-var ftpm tpm2.

Reviewer notes

Build-verified, not hardware-validated. avocado-image-initramfs for
avocado-imx93-frdm with the feature selected: 5025/5025 tasks, 0 errors. The
produced initramfs carries tpm_ftpm_tee.ko, optee-ftpm-init's script, unit,
modprobe.d conf and its initrd-root-fs.target.wants symlink, and
/etc/avocado-security-capabilities reading exactly encrypted-var ftpm tpm2.
No board pass has been run.

The declaration is deliberately narrower than the hardware. ahab is left
off: this board supports it, but nothing on this branch wires it up, and the
declaration is a claim about what the image delivers rather than about the
silicon. The recipe-side assert only runs for machines COMPATIBLE_MACHINE
already matches, so a declaration that overreaches is invisible by
construction - which is why delivery lands first here and the declaration
second.

The OP-TEE version pins are a hold, not a verdict. Adding meta-arm makes
meta-imx's dynamic-layers/meta-arm OP-TEE recipes parse for the first time,
at which point imx-base-extend.inc's existing
PREFERRED_VERSION_optee-os:imx-nxp-bsp ??= "4.10.0.imx" starts resolving and
would silently move the board off 4.8.0 inside the boot chain. All four recipes
are pinned back, not just optee-os, because optee-client provides
tee-supplicant which backs the fTPM's REE-FS storage and a version mismatch
there ships rather than failing. Removing the pins needs its own change and a
hardware pass.

Known warning: a PREFERRED_VERSION for nativesdk-qemu of 8.2.2.imx
does not resolve (available: 10.2.0, 10.2.5.imx). Pre-existing, not
introduced here, and warning-only - but worth an owner's look given how much
this fragment invests in pinning against exactly that class of drift.

Depends on #271. CI has not run yet; these workflows are PR-triggered.

[jetm]

Closing: superseded by #271.

This PR's four commits are all present on imx93-secure-boot-wrynose in reworked form:

• "Front-port the build and image fixes wrynose needs" is already on the base as 17149b8d (the squash merge of Front-port the build and image fixes wrynose needs #267). Its patch-id differs, which is why a rebase stops on it rather than dropping it automatically.
• "Write security capabilities artifact" is superseded by c3410550.
• "bring up the OP-TEE fTPM behind an opt-in" is superseded by dc601b87.
• "Declare ftpm and tpm2 on imx93-frdm" is superseded and would regress the tree. This branch hardcodes AVOCADO_SECURITY_CAPABILITIES = "encrypted-var ftpm tpm2", while the base derives it: "encrypted-var${@bb.utils.contains('MACHINE_FEATURES','optee-ftpm',' ftpm tpm2','',d)}". Merging the hardcoded form would make a board without the fTPM feature claim ftpm tpm2 anyway.

Nothing here is lost. The CONFIG_TRUSTED_KEYS note in ftpm.cfg is on the base in fuller form, and persist_ssh_host_keys now lives in #275/#276, which own that change.

The fTPM path on imx93-secure-boot-wrynose has since been verified on an i.MX93 FRDM, including two defects not present in this branch: btrfs-tools missing from RDEPENDS, and blkid -p's exit status being unusable as a filesystem probe on a GPT partition.