fix(motd): guard against double display on GNOME OS / freedesktop-sdk base

[castrojo]

Problem

On GNOME OS / freedesktop-sdk based images (e.g. dakota), the MOTD fires twice in every interactive login shell session (e.g. Ghostty).

Root cause: freedesktop-sdk's /etc/bashrc unconditionally sources /etc/profile.d/*.sh, while Fedora's /etc/bashrc has a shopt -q login_shell guard that prevents this. This creates a double-source chain:

1. /etc/profile → profile.d → ublue-motd.sh (MOTD Add common system files from bluefin #1)
2. ~/.profile → ~/.bashrc → /etc/bashrc → profile.d → ublue-motd.sh (MOTD Add container build workflow #2)

Production Bluefin (Fedora-based) is unaffected because Fedora's bashrc has the guard. Only freedesktop-sdk based images are affected.

Fix

Add an UBLUE_MOTD_SHOWN=1 guard at the top of ublue-motd.sh — identical pattern to BLING_SOURCED=1 already used in bling.sh in this repo.

Testing

Validated on physical hardware (NUC running dakota):

# Before fix
$ bash --login -i <<< 'echo done' | grep -c 'Welcome to Bluefin'
2

# After fix
$ bash --login -i <<< 'echo done' | grep -c 'Welcome to Bluefin'
1

Upstream issue: projectbluefin/dakota #200

Note: The proper root-cause fix is to patch freedesktop-sdk's /etc/bashrc to add the shopt -q login_shell guard (via dakota's patch_queue). This guard is a defensive fix that also protects against any other future double-source scenarios.

[gemini-code-assist]

Code Review

This pull request introduces a guard against double-sourcing in the ublue-motd.sh script to prevent the message of the day from being displayed multiple times during shell initialization. A review comment correctly identifies that exporting the guard variable could lead to the MOTD being suppressed in subshells or nested login sessions, and suggests using a local shell variable instead.

[gemini-code-assist]

The use of export for the UBLUE_MOTD_SHOWN variable will cause the MOTD to be suppressed in all subshells (including nested login shells) because the variable is inherited by child processes. Furthermore, if the desktop environment sources profile.d during session startup, this variable could be exported to the entire graphical session, preventing the MOTD from appearing in any terminal. Since the issue involves double-sourcing within the same shell process initialization, a local shell variable is sufficient and avoids these side effects. This also aligns with the BLING_SOURCED pattern mentioned in the PR description, which does not use export.

Suggested change

	export UBLUE_MOTD_SHOWN=1
	UBLUE_MOTD_SHOWN=1