⚡ Quick Fix (TL;DR)

The Culprit: Both snippets passed php -l individually and executed cleanly through a full WordPress-function-stub test in isolation. No PHP error appeared anywhere – not the server's own error log, not the code-snippet plugin's internal error log. The failure only showed up as the shortcode tag rendering as literal unprocessed text on the page.

The Fix: Systematic bisection was the only thing that actually worked: deactivating every other active snippet one at a time (ruling out content, size, and execution order along the way) eventually proved the interference was specific to how the snippet-management plugin combines multiple "Run Everywhere" PHP snippets into one execution context – not a bug in either snippet's own code. The practical fix was converting both snippets into standalone plugin files instead, which fully resolved it. When two provably-correct pieces of code fail only in combination and never independently, suspect the platform combining them, not either piece itself.

Update: the plugin/support team confirmed the general mechanism – all active "Run Everywhere" PHP snippets are combined into one execution block, run in priority-then-creation order – but attributed the specific failure to a pattern (a top-level return, a trailing closing tag, or an unclosed comment) that turned out not to actually be present in the offending snippet's source after a careful re-check. Setting the new snippet's Priority to 1, forcing it to run before the older one, resolved the conflict directly – confirming priority ordering as a working lever even though the exact root cause of the original failure remains unconfirmed. If a future "Run Everywhere" PHP snippet doesn't register for no visible reason, try lowering its Priority before assuming a deeper problem.