Here's something that might help someone else. I'm not sure if it's due to my "cheapest I could find" EXVIST H.264/H.265 encoder or something else entirely, but sometimes (not always) channels DVR says it sees EOF soon after the actual video starts playing.
2024/08/05 15:54:28.454989 [SNR] Buffer statistics for "TV/Alma's Way/Alma's Way S01E11 2021-10-19 Socks for Sale Almas Anim 2024-08-05-1554.mpg": buf=0% drop=0%
2024/08/05 15:54:28.459657 [DVR] Job 1722898417-chKHET Alma's Way ended prematurely: 5m31.540346421s
As a result, it closes the connection, and ah4c runs the stop script. If it's a record job in channels DVR, it tries again and again and does not succeed (because it starts the turning process from the beginning each time).
There's a lot I don't know about MPEGTS, but I suspect that when the video starts playing either the software on my device or the firmware on the decoder says, "well, things have changed, so I'm going to end that stream and start a new one". I poked around a bit and tried a lot of things in my knuckle-dragging way. Without understanding what is actually going on, I have finally hit upon something that works around the problem.
The TSDuck toolkit is able to analyze and do a lot of things with transport streams. It's possible to use it as a very simple streaming server at the output of its pipeline. It can also be configured to overlook a few things, like an unexpected EOF. For the EOF thing, you can tell it to go back to the source and start reading again. With those things, I was able to construct a simple proxy that reads the stream out of my encoder and makes it available for chanels DVR (via ah4c). Since there is no transcoding, it doesn't use much resource.
If you have a similar problem or if you just want to see more details, there is a docker image on Docker hub at wjcarpenter/tsduck-proxy. The artifacts for building that docker image can be found in this GitLab repo: tsduck-proxy · main · WJCarpenter / tv scraps · GitLab