fix(output): make file rendering non-destructive and the PPTX target explicit

[DemchaAV]

Stacked on #436. Base is chore/release-2.1-line so the diff shows only this change — both branches edit the v2.1.0 CHANGELOG section. Retarget to develop before #436 merges, or GitHub closes this PR.

Why

Rendering to a file opened the destination before the backend produced a byte, so the file was truncated first and written second. A render that then failed — an atomic node taller than the page, a missing backend, a full disk — replaced a published document with an empty one. That is the exact shape of the library's main use case: a server re-rendering a document it is already serving.

Separately, DocumentSession holds one configured output path shared with buildPdf(), so the no-arg buildPptx() wrote deck bytes into whatever that path was. Its own Javadoc had to warn that a .pdf default would receive a PPTX.

And BackendProviders.fixedLayout(format) took the first ServiceLoader match, so a third-party provider declaring an already-registered format silently decided which backend rendered the document, depending on classpath order.

What changed

• Non-destructive file output. Both file paths render into a scratch file in the destination's own directory, moved onto the destination only after the render returns normally. The move is atomic where the filesystem supports it, so a concurrent reader never sees a half-written document, and the scratch file is discarded on failure without masking the render's own exception. Two details the naive form gets wrong are handled explicitly: Files.createTempFile creates owner-only and Files.move carries that mode onto the destination — silently narrowing a served file — so POSIX permissions are aligned to the destination's existing mode (or rw-r--r-- for a new file) before the move; and replacing the destination entry replaces a symlink rather than writing through it, which the contract now states.
• DocumentSession.buildPptx() (no-arg) removed; buildPptx(Path) stays. Naming the destination is also what lets one session emit both formats. The surface is @Beta and unpublished — graph-compose-core at the 2.0.0 baseline does not declare the method, which is why the binary-compatibility gate stays green. The real risk was javadoc:javadoc: two {@link} references lived in the examples module.
• Duplicate backend formats fail fast. Both the by-format lookup and the no-arg default share one resolver that throws IllegalStateException naming the competing provider classes.

Verification

• ./mvnw -B -ntp clean verify — BUILD SUCCESS, 1518 tests (from 1508), 0 failures, 2 skipped off POSIX.
• The regression test was proven, not assumed: reverting DocumentRenderingFacade to Files.newOutputStream(target) turns DocumentOutputFileSafetyTest red with expected: "previously published document" but was: "".
• ./mvnw -P japicmp verify -pl :graph-compose-core — green; git show v2.0.0:…/DocumentSession.java | grep -c buildPptx is 0.
• javadoc:javadoc green on the six published modules and on examples.
• New coverage: mid-stream failure, scratch cleanup, first-time creation, missing parent directory, POSIX permission alignment, and two ServiceLoader fakes sharing one format with a companion test proving unrelated formats still resolve.