docs: document parallel_export_parquet; fix stale superuser claims after #331

[ChronicallyJD]

What

Follow-up docs audit for the last two days of features. Two gaps.

1. parallel_export_parquet was undocumented in the reference docs. It shipped
in #329 and appears in administration.md's privilege table, but had no
sql-reference.md entry, no features.md note, and no user-guide.md example,
unlike its sibling parallel_copy. Added all three, including the consistency
guarantee (one exported snapshot, so the files are the committed image at call
time) and the partial-output cleanup on failure (#332).

2. Six stale "require superuser" claims. #330 and #331 moved the server-file
functions to the pg_read_server_files and pg_write_server_files roles, which
superusers hold. administration.md was updated then, but these were missed:

• sql-reference.md: the import/export intro and the read-in-place section
• features.md: the interoperability note
• user-guide.md: the read-in-place note
• limitations.md: the type-coverage note and the read-in-place limits

The two remaining superuser mentions in configuration.md are GUC-set
permissions, not server-file access, and are correct.

ste_check.py and docs_style.sh pass on the full docs set.

🤖 Generated with Claude Code

[ChronicallyJD]

Review: accurate, and the stale-claim sweep is complete. One sentence is wrong.

The #331 cleanup is done properly. grep -rn "requires superuser\|superuser only\|must be superuser" docs/*.md on the branch returns nothing, so the blanket claim that started #330 is gone everywhere rather than just where it was noticed. The
replacement wording, "which superusers hold", is the right way to say it: the role
is the gate, and superuser satisfies it, without reintroducing the old claim.

The parallel_export_parquet entry checks out against the code: the
pg_write_server_files role plus SELECT on the target, the two supported target
shapes, one file per partition on the partitioned path, and the read-only exported
snapshot. That last one matters and is stated correctly, since it is what makes the
directory a point-in-time image rather than a smear.

The wrong sentence

The output directory must exist and be empty.

It does not have to exist. pexport_prepare_dir says so in its own header,
"Create the output directory if absent; require it empty if it exists", and it
behaves that way:

directory exists beforehand? no
export to a NON-EXISTENT directory -> 1000     (succeeded)
directory exists after?  yes   files: 1

So a user reading this will create the directory first, believing they have to.
Harmless in itself, but the sentence also obscures the half that does matter: the
constraint is emptiness, not existence, and that is the one that will bite someone
re-running an export into a directory that already has output. "The output
directory must be empty; it is created if it does not exist" covers both.

Worth a second look at the same sentence in the sql-reference entry if it is
duplicated there.

Small suggestion

Now that #333 landed, the failure behaviour is worth one line wherever the empty
requirement is stated: a failed or cancelled export removes the part files it
wrote, so a retry is not blocked. That is the user-visible consequence of the
cleanup, and without it the emptiness rule reads as a trap after any failure.

test/docs_style.sh passes on the branch.