PostgreSQL log reads: a split multi-byte character logs a false ERROR, pgBadger prefixes lose user and database, unbracketed %p prefixes are unreadable, cut deadlock reports stored twice #4735

Four small defects in the PostgreSQL log reads, all in PerformanceMonitor.Collectors unless noted. Line numbers are as of 1248a67, before #4704 changed the log tail. Item 1 was checked again on current dev.

1. The tail's start offset can split a multi-byte character, and the cycle logs a false ERROR

PgServerLogTail.cs:125-128 and PgReadBinaryFileCapability.cs:23-28. Sometimes there is no resume position: on the first read of a file, or after a fallback. The text read then starts TailBytes before the end of the file. PostgreSQL checks the encoding of the slice, so non-ASCII text in a large log can make it fail.

Only the pg_read_file text route fails, but it is the default until the login gets EXECUTE on pg_read_binary_file. The next cycle usually succeeds, and the overlap covers the gap. What remains is a false ERROR row whose text blames a planted byte.

Expected: retry with the offset moved by 1 to 3 bytes, and correct the message. Reading from earlier and skipping to the first newline does not work, because the server rejects the slice before the client sees it.

2. The stderr prefix parser takes user and database only from user@db

PgLogEntryAssembler.cs:246-248. The common pgBadger prefix (user=%u,db=%d) gives a null user and database on error rows. The tool description already mentions this.

Expected: also match user= and db=.

Test: an error line with a pgBadger prefix yields the user and the database.

3. A log prefix with an unbracketed %p cannot be read, and plan-capture readiness cannot tell

Lines with the prefixes %m %p, %t %p: or %t [%p-%l] are dropped. The plan-capture readiness check looks only at %Q (PgPlanCaptureReadinessCollector.cs:156,315), so the target reads as quiet.

Expected: a readiness facet for the prefix, so an unreadable prefix is reported instead of looking quiet.

Test: each of the three prefixes gives the facet.

4. A deadlock report cut at the end of a read is stored twice, and on RDS only the fragment is stored

The cut report hashes differently from the full report that the next cycle reads, so it is stored twice (the same shape as #3009). On RDS the rest of the report is never offered again, so only the fragment is stored.

Expected: treat a deadlock block with no trailing HINT as unfinished. On the self-hosted route, skip it, because the next read has it whole. On RDS, carry it into the next chunk (Darling/PerformanceMonitor.Darling.Service/Targets/RdsLogSource.cs, after #4713).

Test: a block cut before its HINT is not stored until it is whole.