The symptoms were a circus. The application could not write its session store. Then it could not write logs, so the logs stopped helpfully right before the interesting part. Then systemd started complaining it could not record journal entries. Three different subsystems failing in three different ways, and for a good ten minutes I was convinced I was chasing some subtle interaction between them.
It was /var. It was full. df -h would have told me in two seconds, which is exactly why it is the first thing you are supposed to run and exactly the thing I skipped because I'd decided this was a "proper" problem.
The culprit was a log file that had escaped rotation. An application was writing verbose debug output, someone had bumped its log level for an investigation weeks earlier, the logrotate rule did not cover that particular path, and it had quietly grown to fill the partition. Everything downstream of "can write to disk" then failed, in whatever order each subsystem happened to try, which is why it looked like several unrelated faults instead of one.
The fix took longer to type than to think about: truncate the runaway file, put the log level back, add the path to logrotate, and set a disk-usage alert at eighty percent so the next one shouts before it bites. The lesson is the oldest one in the book and I will keep relearning it forever: when a healthy system suddenly fails in three places at once, check the boring resources first. It is almost always disk, memory, or file descriptors, and it is almost never as clever as you fear.