Add copilot instructions

[atobiszei]

🛠 Summary

JIRA/Issue if applicable.
Describe the changes.

🧪 Checklist

• Unit tests added.
• The documentation updated.
• Change follows security best practices.
  ``

[Copilot]

Pull request overview

Adds a repository-level .github/copilot-instructions.md file to guide GitHub Copilot usage for OVMS, focusing on repo structure, build/test workflows (Bazel + Docker/Make), and C++ code review expectations.

Changes:

• Introduces Copilot instructions describing OVMS architecture, build system, and testing workflow.
• Documents common Bazel/Make/Docker commands and target/stage references.
• Adds a PR review checklist tailored to OVMS C++ performance, style, and testing practices.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mzegla]

I would drop Python bindings parts.
Python bindings are not changing nor expected to change any time soon.
The binding is also not a OVMS C++ API binding, but just pyovms for Python code execution in OVMS. I don't think it's worth having here.

[atobiszei]

Suggested change

	4. **Python bindings**: if C++ APIs change, check whether the corresponding pybind11 wrappers in `src/python/` need updates.
	5. **Documentation**: ensure new public APIs have docstrings in C++ headers and Python bindings; update `docs/` as needed.
	6. **Test coverage**: ensure that new features or changes have corresponding tests in `src/test/`.
	7. **Formatting & safety:**
	- No `using namespace std; using namespace ov;`. Prefer explicit using with specific symbols if needed, for readability.
	- No `auto` for primitive types where it obscures readability.
	- Use `const` and `constexpr` wherever possible.
	8. Pass non-fundamental values by `const` reference wherever possible.
	9. Prefer member initializer lists over direct assignments in constructor bodies.
	10. Verify that the result of every newly introduced function is used in at least one call site (except `void` functions).
	11. Use descriptive function and variable names. Avoid duplicate code — extract common functionality into reusable utilities.
	12. When initial container values are known upfront, prefer initializer-list / brace-initialization over constructing an empty container and inserting.
	13. Unused functions and includes are not allowed. Build times are already long — do not add unnecessary `#include` directives. Prefer forward declarations where possible and follow the include-what-you-use principle.
	- **Forward-declare in headers, include in `.cpp`**: if a header only uses pointers or references to a type, use a forward declaration (`class Foo;`) instead of `#include "foo.hpp"`. Move the full `#include` to the `.cpp` file where the type is actually used.
	- **Keep headers self-contained but minimal**: each header must compile on its own, but should not pull in transitive dependencies that callers don't need.
	- **Prefer opaque types / Pimpl**: for complex implementation details, consider the Pimpl idiom to keep implementation-only types out of the public header entirely.
	- **Never include a header solely for a typedef or enum**: forward-declare the enum (`enum class Foo;` in C++17) or relocate the typedef to a lightweight `fwd.hpp`-style header.
	14. Be mindful when accepting `const T&` in constructors or functions that store the reference: verify that the referenced object's lifetime outlives the usage to avoid dangling references.
	4. **Documentation**: ensure new public APIs have docstrings in C++ headers and Python bindings; update `docs/` as needed.
	5. **Test coverage**: ensure that new features or changes have corresponding tests in `src/test/`.
	6. **Formatting & safety:**
	- No `using namespace std; using namespace ov;`. Prefer explicit using with specific symbols if needed, for readability.
	- No `auto` for primitive types where it obscures readability.
	- Use `const` and `constexpr` wherever possible.
	7. Pass non-fundamental values by `const` reference wherever possible.
	8. Prefer member initializer lists over direct assignments in constructor bodies.
	9. Verify that the result of every newly introduced function is used in at least one call site (except `void` functions).
	10. Use descriptive function and variable names. Avoid duplicate code — extract common functionality into reusable utilities.
	11. When initial container values are known upfront, prefer initializer-list / brace-initialization over constructing an empty container and inserting.
	12. Unused functions and includes are not allowed. Build times are already long — do not add unnecessary `#include` directives. Prefer forward declarations where possible and follow the include-what-you-use principle.
	- **Forward-declare in headers, include in `.cpp`**: if a header only uses pointers or references to a type, use a forward declaration (`class Foo;`) instead of `#include "foo.hpp"`. Move the full `#include` to the `.cpp` file where the type is actually used.
	- **Keep headers self-contained but minimal**: each header must compile on its own, but should not pull in transitive dependencies that callers don't need.
	- **Prefer opaque types / Pimpl**: for complex implementation details, consider the Pimpl idiom to keep implementation-only types out of the public header entirely.
	- **Never include a header solely for a typedef or enum**: forward-declare the enum (`enum class Foo;` in C++17) or relocate the typedef to a lightweight `fwd.hpp`-style header.
	13. Be mindful when accepting `const T&` in constructors or functions that store the reference: verify that the referenced object's lifetime outlives the usage to avoid dangling references.

[atobiszei]

Suggested change

| `//src/python/binding:test_python_binding` | Python binding tests |