Only core prunes the message of the day drop-ins of another product

[marcos-mendez]

Keel-Linux/keel-core#9 removes the two message of the day drop-ins that
speak for another product, in conf.d/main of the core recipe, because an
overlay can add a file and cannot remove one. That is enough for the way
Keel ships and not enough for every way a recipe can be built.

Why it is enough today. bt-layer subtracts the parent's common_conf
from the child's, so no appliance built on core re-runs
common/conf/turnkey.d/motd. Measured on the build host on 2026-09-28,
the mariadb, wordpress, redis and postgresql layer tarballs carry no
/etc/update-motd.d entries at all: core's removals are what every layer
above it inherits.

Where it is not. A plain make of a non-core recipe runs with the full
COMMON_CONF and no parent to subtract it, so conf/turnkey.d/motd writes
00-turnkey-sysinfo and 08-turnkey-confconsole again and nothing removes
them. That image welcomes the operator twice and tells them to run
tklbam-init, and keel_motd_check_dir is not called there to catch it.
The ISO path and an M0-style full build are built that way, so this is not
hypothetical.

What closes it. Either the same two calls in every recipe's conf.d:

. /usr/lib/keel/motd.sh
keel_motd_prune_dir /etc/update-motd.d
keel_motd_check_dir /etc/update-motd.d

or the arrangement asserted somewhere that is not one product's conf script.
The recipes: keel-apache-php, keel-lamp, keel-lapp, keel-mariadb,
keel-nodebb, keel-nodejs-nginx, keel-postgresql, keel-redis,
keel-transition, keel-wordpress.

Recorded rather than solved in keel-core#9 by agreement with the review:
every appliance Keel ships is strictly better off with that change and none
regresses, so it should not wait for this. The limit is written down in
conf.d/main and COVERAGE.md of keel-core.

Context: #6, Keel-Linux/keel-core#7, handbook decision 0014.