systemd service fails after pacman upgrade but journalctl shows no error output

Goal

Determine why a systemd-managed deployment service fails to start after a routine pacman system upgrade, yet journalctl -u returns no visible error messages for the unit.

Constraints

The service unit is enabled and was running before the upgrade. Pacman's transaction log confirms the relevant packages were updated. Journal persistence is configured with Storage=persistent in journald.conf, and the journalctl --vacuum-time retention window should cover the failure period. Non-root access to the journal is granted via the systemd-journal group.

Uncertainty

It is unclear whether the failure originates from a missing dependency pulled by the upgrade, a configuration file conflict that systemd does not surface, or a silent exec failure that bypasses standard logging. The absence of journal entries despite persistent storage raises questions about the logging pipeline for this specific unit.

Questions

1. What conditions cause a systemd service to fail without writing to the journal when Storage=persistent is set?
2. How can the pacman transaction log be correlated with systemd unit state changes to identify the triggering package change?
3. Does systemd suppress output for services that fail during the ExecStartPre phase before the main process spawns?