Render release-note planning previews

[cachafla]

What changed

• include previews/** when checking out release-notes PR revisions
• select previews/<version> as a targeted render directory alongside versioned releases/**
• populate preview sources into the documentation tree before rendering

Why

Release planning previews are intentionally stored outside releases/** so they cannot enter normal release publication. The release-notes PR preview workflow needs a receiver that can render this isolated source path into its PR-specific staging prefix.

This PR must merge before validmind/release-notes#123 is marked ready for review.

Validation

• workflow YAML parses successfully
• preview target selector resolves previews/26.08 and existing release targets correctly
• existing test_merge_quarto_indexes.py suite: 3 passed
• simulated receiver population and quarto render --profile development previews/26.08
• rendered _site/previews/26.08/release-notes.html with no warnings or errors

[github-actions]

PR Summary

This PR extends the GitHub Actions workflow for generating release notes by adding support for preview directories. The main changes are:

• Addition of the 'previews' directory to the sparse-checkout configuration, enabling the workflow to include both release and preview content.
• Modification of the diff command that selects changed directories to handle both 'releases' and 'previews'. Specifically, the AWK script now:
  • Processes paths under the 'releases' directory with at least 4 components.
  • Processes paths under the 'previews' directory with at least 3 components.
• Updates to log messages to reflect the inclusion of preview directories in the process.
• Inclusion of conditional logic to copy the preview directory from the source if it exists, ensuring that preview release notes are generated alongside regular releases.

Test Suggestions

• Test with changes only in the 'releases' directory to ensure that the workflow behaves as expected.
• Test with changes only in the 'previews' directory to validate that the workflow detects and processes preview directories correctly.
• Test with changes in both directories to confirm that both sets of changes are handled and logged.
• Verify that the output file (.release-preview-targets) correctly lists directories from both 'releases' and 'previews' and that the log messages accurately reflect these changes.
• Test the conditional copying of the 'previews' directory when it exists and confirm that the file structure is maintained in the target directory.

[github-actions]

Validate docs site

✓ INFO: A live preview of the docs site is available — Open the preview

[github-actions]

Lighthouse check results

✓ INFO: No site pages to audit in this PR.

Commit SHA: e1afebe