Unusual postmaster fork pattern under auth enabled: 1 child → 7 grandchildren

[yugabyte-ci]

Jira Link: DB-21350
While running the overlapping_query_spike stress test with auth enabled, bpftrace on sched_process_fork revealed an unexpected process tree: a PID directly forked by the postmaster goes on to fork 7 additional postgres PIDs. Under normal operation, postmaster-forked backends shouldn't themselves fork more postgres processes for connection handling — the postmaster forks one backend per connection, and that's it.
The pattern is consistent: postmaster forks one child, that child fans out to exactly 7 grandchildren, and the cycle repeats for each new connection burst. This was surfaced while investigating elevated PID counts during the spike test; the PID counts themselves are roughly explainable (~2x–3x of accepted + rejected connections is expected), but the fork chain isn't.
Trace command

bashsudo bpftrace -e 'tracepoint:sched:sched_process_fork /args->child_comm == "postgres"/ {
  printf("%s pid=%d forked child pid=%d\n", args->parent_comm, args->parent_pid, args->child_pid);
}'

Sample output

postgres pid=11804 forked child pid=40185
postgres pid=40185 forked child pid=40186
postgres pid=40185 forked child pid=40187
postgres pid=40185 forked child pid=40188
postgres pid=40185 forked child pid=40189
postgres pid=40185 forked child pid=40190
postgres pid=40185 forked child pid=40191
postgres pid=40185 forked child pid=40192
postgres pid=11804 forked child pid=40197
postgres pid=40197 forked child pid=40198
postgres pid=40197 forked child pid=40199
postgres pid=40197 forked child pid=40200
postgres pid=40197 forked child pid=40201
postgres pid=40197 forked child pid=40202
postgres pid=40197 forked child pid=40203
postgres pid=40197 forked child pid=40204

11804 is the postmaster → forks 40185 → which forks 40186–40192 (7 children). Same shape repeats with 40197 → 40198–40204.