Extend copilot-instructions.md (openvinotoolkit#3285)

## Description
From
openvinotoolkit#2707 (comment)
and
openvinotoolkit#3267 (comment)

## Checklist:
- [x] This PR follows GenAI Contributing guidelines. <!-- Always follow
https://github.com/openvinotoolkit/openvino.genai?tab=contributing-ov-file#contributing.
If there are deviations, explain what and why. -->
- N/A Tests have been updated or added to cover the new code. <!--
Specify exactly which tests were added or updated. If the change isn't
maintenance related, update the tests at
https://github.com/openvinotoolkit/openvino.genai/tree/master/tests or
explain in the description why the tests don't need an update. -->
- N/A This PR fully addresses the ticket. <!--- If not, explain clearly
what is covered and what is not. If follow-up pull requests are needed,
specify in the description. -->
- N/A I have made corresponding changes to the documentation. <!-- Run
github.com/\<username>/openvino.genai/actions/workflows/deploy_gh_pages.yml
on your fork with your branch as a parameter to deploy a test version
with the updated content. Replace this comment with the link to the
built docs. If the documentation is updated in a separate PR, clearly
specify it. -->

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Alexander Suvorov <alexander.suvorov@intel.com>

Author: 3 people

.github/copilot-instructions.md

@@ -16,14 +16,28 @@ You are the OpenVINO GenAI Reviewer. Your mission is to ensure that all new code
 
 ## Code Review Instructions for PRs
 When analyzing a Pull Request, follow this protocol:
-1. Check for 'Hidden' Performance Tax: Look for dynamic_cast in the hot path (inference loops). Suggest static_cast or redesigning if the type is known.
-2. Avoid copies: Ensure that large data structures (like tensors) are passed by reference or moved, not copied.
-3. Python Bindings: If C++ APIs are changed, check if the corresponding Python pybind11 wrappers in src/python need updates.
-4. Exceptions: Use OPENVINO_ASSERT(condition, ...) for checks instead of if + throw.
-5. Documentation: Ensure that any new public APIs have docstrings in C++ headers and Python bindings. Ensure that new public APIs have documentation updated in /site.
-6. Test Coverage: Ensure that new features or changes have corresponding tests.
-7. Formatting & Safety:
-    * No using namespace std;.
-    * No auto for primitive types where it obscures readability.
-    * User `const` and `constexpr` wherever possible.
-8. Assumptions on user behalf aren't allowed. For example, the implementation shouldn't adjust config values silently or with a warning; it should throw an exception instead.
+1. Follow C++ Core Guidelines strictly. Include references in your comments.
+2. Check for 'Hidden' Performance Tax: Look for dynamic_cast in the hot path (inference loops). Suggest static_cast or redesigning if the type is known.
+3. Avoid copies: Ensure that large data structures (like tensors) are passed by reference or moved, not copied.
+4. Python Bindings: If C++ APIs are changed, check if the corresponding Python pybind11 wrappers in src/python need updates.
+5. Exceptions: Use OPENVINO_ASSERT(condition, ...) for checks instead of if + throw.
+6. Documentation: Ensure that any new public APIs have docstrings in C++ headers and Python bindings. Ensure that new public APIs have documentation updated in /site.
+7. Test Coverage: Ensure that new features or changes have corresponding tests.
+8. Formatting & Safety:
+    * No `using namespace std;`.
+    * No `auto` for primitive types where it obscures readability.
+    * Use `const` and `constexpr` wherever possible.
+9. Pass non-fundamental values by `const` reference wherever possible.
+10. Follow constructors and member initializer lists style instead of direct assignments in the constructor body.
+11. Verify that the result of every newly introduced function is used in at least one call site except for `void` functions.
+12. Make sure the function names are descriptive.
+13. Check for variables with different names but similar meaning or aliasing.
+14. Avoid duplicate code. Ensure that common functionality is extracted into reusable functions or utilities.
+15. Avoid pronouns in comments and names to make the statements concise.
+16. Unused functions and constructors aren't allowed except for in `debug_utils.hpp`.
+17. `debug_utils.hpp` must never be included.
+18. Assumptions on user behalf aren't allowed. For example, the implementation shouldn't adjust config values silently or with a warning; it should throw an exception instead.
+19. Samples:
+    * Avoid adding new samples unless there is a strong, clearly justified reason.
+    * Keep command‑line arguments in samples minimal.
+    * Ensure new samples have corresponding tests.