Hm… This does look like you might have either disk corruption or a mangled Consul state.
I don’t know the Fly Postgres internals well enough to say what exact surgery could be done, however.
Personally, I would try the volume-forking technique (with explicit volume ID) and see whether the new DB app still shows those anomalies.
(I don’t recall whether that works on Stolon-era databases, now that I think about it. If not, there’s a similar procedure based on snapshots.)
Yep, Flycast apps will have an address of TYPE = private and VERSION = v6. It’s not clear whether that add_flycast command has really been maintained, though. Glancing at the source code, it modifies the [[services]] definitions but doesn’t actually allocate the address, 
.
Other things that can be checked are fly dig db-app-name.flycast and fly services list -a db-app-name. (“Services” in this context meaning things that the Fly Proxy intermediates. It wasn’t involved with the .internal traffic.)
Hope this helps a little!