What does "database is not accepting commands to avoid wraparound data loss" mean?

It means freezing fell so far behind that the server has refused to issue any more transaction ids in that database, to protect rows that would otherwise become unreadable. Current wording names the mechanism precisely: commands that assign new transaction ids are refused. Plain reads still work. The cure is a database-wide vacuum, and the thing to find first is whatever stopped the earlier ones from succeeding.

The part that is genuinely urgent, and the part that is not

Urgent: every write in that database is refused right now, so the application is down for anything but reading.

Not urgent in the way the wording suggests: no data has been lost, nothing is corrupt, and the server stopped precisely so that nothing would be. There is a deliberate reserve of transaction ids left unused underneath the cutoff, and it exists so that an administrator has room to work. You are inside the safety margin, not past it.

The instinct this triggers is to restart into single-user mode, because that is what the hint used to say and what a decade of forum answers still say. Do not. The documentation is now explicit that stopping the server is neither necessary nor desirable in a typical recovery, and doing it converts a read-only database into no database at all for the length of the vacuum. Single-user mode has one remaining use, which is dropping or truncating tables you have decided not to vacuum at all.

Why it got here, which is the question that matters

Autovacuum does not simply fail to run for months. It runs, and it is refused permission to advance the frozen bookkeeping, because something older than the rows it wants to freeze is still entitled to see them. In practice that is one of four things: a transaction somebody left open, a replication slot with no consumer, a prepared transaction nobody committed, or a standby whose feedback is pinning the primary.

Fixing the vacuum without removing the holder means the same message returns, on the same table, at the same hour of the night. So identify the holder first, release it, then vacuum. The order is the whole trick.

Transaction id wraparound covers the identification step and the alerting that would have caught this several weeks earlier, when the warnings began and were logged into a file nobody reads. The reason an emergency vacuum ignores its own throttling once the age gets extreme is the failsafe, and seeing it engage in the log is a signal in its own right.