[docs] Add examples.yml header instructions

[linh285]

Description

This PR closes #44388 by adding header comments to the examples.yml files used to generate the Examples Gallery pages.

The comments clarify that:

• the generated examples.rst pages should not be edited directly;
• formatting changes to the generated pages should be requested through a docs issue;
• generated pages should be referenced with examples.html;
• new examples should include skill level and framework information when applicable.

Related issues

Closes #44388

Additional information

This is a docs-only change. No runtime code was modified.

Checks:

• Verified that only the three requested examples.yml files were changed.
• Ran git diff --check.
• Checked the files with PyYAML.

[gemini-code-assist]

Code Review

This pull request adds header comments to several YAML configuration files (examples.yml for data, serve, and train) to guide developers on how the Examples Gallery pages are auto-generated and referenced. The reviewer points out that hardcoding .html extensions in the reference instructions is a Sphinx anti-pattern, and recommends using the :doc: role instead to ensure proper link validation and compatibility with other builders.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

In Sphinx, referencing other documentation pages should be done using the :doc: role (e.g., :doc:/data/examples) rather than hardcoding the .html extension.

Hardcoding .html links is an anti-pattern in Sphinx because:

1. It bypasses Sphinx's link validation (Sphinx won't warn you if the target file is moved or deleted).
2. It can break if the documentation is built using a non-HTML builder (like PDF or EPUB).

Consider updating this instruction to recommend the :doc: role:

To reference the generated page, use :doc:/data/examples.

[gemini-code-assist]

In Sphinx, referencing other documentation pages should be done using the :doc: role (e.g., :doc:/serve/examples) rather than hardcoding the .html extension.

Hardcoding .html links is an anti-pattern in Sphinx because:

1. It bypasses Sphinx's link validation (Sphinx won't warn you if the target file is moved or deleted).
2. It can break if the documentation is built using a non-HTML builder (like PDF or EPUB).

Consider updating this instruction to recommend the :doc: role:

To reference the generated page, use :doc:/serve/examples.

[gemini-code-assist]

In Sphinx, referencing other documentation pages should be done using the :doc: role (e.g., :doc:/train/examples) rather than hardcoding the .html extension.

Hardcoding .html links is an anti-pattern in Sphinx because:

1. It bypasses Sphinx's link validation (Sphinx won't warn you if the target file is moved or deleted).
2. It can break if the documentation is built using a non-HTML builder (like PDF or EPUB).

Consider updating this instruction to recommend the :doc: role:

To reference the generated page, use :doc:/train/examples.