[andygrove]

Which issue does this PR close?

Part of #6550. This is the "Generate release documentation" step of the release process.

Rationale for this change

On main, docs/source/user-guide/latest/ holds template markers and CI fills them at publish time. A release branch commits the generated content, so the archived docs for 1.2.0 render real tables.

What changes are included in this PR?

The output of ./dev/generate-release-docs.sh on branch-1.2 at 286be994d2 (after #7290), with no hand edits except the prettier fix below:

• configs.md: the generated config tables for all ten categories.
• expressions.md: the Implementation column, refreshed from the serde registered on this branch. The 18 changed lines bring it in line with the code. The values follow the same pattern as the 1.1.0 release docs, for example mode and hour are —, << is Native and cast is Hybrid.
• compatibility/expressions/spark-3.4, spark-3.5, spark-4.0, spark-4.1 and spark-4.2: the per-Spark-version compatibility pages, 10 files each. 1.1.0 had four of these directories, and 4.2 is new.

The script ran one Maven build per profile, and all five succeeded. A second commit adds one blank line before <!--END:EXPR_COMPAT--> in 40 of the generated pages. The script formats with whichever prettier npx finds locally, and the CI check installs the latest prettier, which wants that blank line. Prettier 3.9.10 passes on docs/source/user-guide/latest/ with both commits.

How are these changes tested?

The files are generated, so there is nothing to run beyond the script itself. I did not read through the generated tables line by line.

#7291 adds one entry to the changelog and doesn't touch these files, so merge order doesn't matter. Anything else that changes a config's description or default, or the supported expressions, needs these docs regenerated.

[mbutrovich]

Reviewed the mechanism mostly, not the actual product too closely. Thanks @andygrove!