doc: add short-lived Pi documentation automation

Please also confirm the following

• I searched the NeMo Guardrails issue tracker and did not find an existing issue for this automation.

Issue Kind

Improving documentation

Existing Link

https://github.com/NVIDIA-NeMo/Guardrails/tree/develop/docs

Description

Add three GitHub Actions workflows that use short-lived Pi agents inside isolated OpenShell sandboxes to keep public documentation aligned with product development and releases.

Post-merge documentation fast follow

After a development pull request merges into develop, run a documentation-impact pass over only that merged pull request's exact base-to-merge delta. When public documentation needs an update, create one draft documentation pull request dedicated to that development pull request.

The generated pull request must:

• contain only documentation changes derived from the triggering development pull request, rather than accumulating changes from multiple merges;
• limit writes to the repository's public documentation surfaces;
• identify the triggering pull request and exact merge commit;
• request review from the maintainers and the author of the triggering development pull request;
• create no pull request when the exact delta requires no documentation change; and
• use a fresh sandbox that is deleted after the run.

Release documentation

After maintainers merge the bot-authored pull request created by Prepare Release, run a release-specific documentation pass over the generated changelog and merged release tree.

The workflow must:

• accept only the expected stable release branch, title, bot author, labels, and generated file set;
• create source-grounded release notes that include every generated breaking change and summarize consequential features, enhancements, and fixes;
• add the stable version to fern/docs.yml with an immutable fern-docs-snapshot-vX.Y.Z ref;
• update the versioning example in docs/README.mdx without upgrading the Fern CLI;
• create the snapshot commit from the exact release merge and restrict it to the release notes and Fern version registry;
• publish the managed branch and new snapshot tag atomically, then open a draft pull request labeled documentation, release, and automated for maintainer review; and
• exclude the release preparation pull request from the generic post-merge documentation workflow.

Documentation review

For pull requests that change docs/** or another checked-in public-documentation surface, start a fresh read-only Pi sandbox and review the complete merge-base delta. Also support a trusted /review-doc pull-request comment command for an authorized manual rerun.

The review must:

• follow trusted Guardrails repository and documentation instructions from the base revision;
• treat pull-request content as untrusted evidence;
• verify claims against current source, tests, examples, and related documentation;
• use the approved internal documentation-quality rubric and scoring guidance with recorded provenance that does not identify internal products;
• report category scores and a total score from 0 through 100;
• bind the result to the reviewed head commit and replace or mark stale earlier results;
• remain read-only and advisory; and
• keep GitHub write credentials and the upstream model credential outside the model sandbox.

Acceptance evidence

• Tests cover exact single-PR range selection, release-workflow selection and exclusion, documentation-path allowlists, stable release metadata, no-change behavior, reviewer selection, manual-command authorization, stale-head handling, rubric validation, and sandbox cleanup.
• Workflow validation, repository pre-commit checks, and strict Fern validation pass.
• The contributor and maintainer documentation explains triggers, security boundaries, outputs, snapshot immutability, recovery, and required repository secrets or variables.