refactor: convert LineZone docstring example to doctest

[vincenzonetti]

Before submitting

• Self-reviewed the code
• Updated documentation, follow Google-style
• Added docs entry for autogeneration (if new functions/classes)

Description

i converted static docstring examples to doctest format for the LineZones file

Type of Change

• 📝 Documentation update

Motivation and Context

Part of #2106

Additional note

It's actually my first PR on the project. I have only changed one file, but if the change happens to be correct, I could improve this PR by doing the conversion on more files.

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 77%. Comparing base (62efdee) to head (0987b6c).
⚠️ Report is 1 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff           @@
##           develop   #2207   +/-   ##
=======================================
  Coverage       77%     77%           
=======================================
  Files           66      66           
  Lines         8189    8189           
=======================================
  Hits          6303    6303           
  Misses        1886    1886           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Copilot]

Pull request overview

This PR updates the LineZone class documentation by converting its docstring example into a doctest-friendly interactive session, supporting the repo-wide goal of continuously validating documentation examples.

Changes:

• Replaced the previous static Markdown example in LineZone’s docstring with a minimal >>>-style doctest example.

[vincenzonetti]

@Borda I've updated the LineZone example following your suggestions:

1. Wrapped the example in ```pycon ``` fences.
2. Used a trivial frames_generator to keep the loop pattern.
3. Added a second frame to demonstrate and validate an actual crossing (where in_count increments).

Regarding the other files (like Detections class in core.py), many examples depend on external libraries like torch, ultralytics, or transformers which are not installed in the default CI environment. Is using # doctest: +SKIP for these imports and model calls the preferred approach in this project, or should we aim for a different way to make them verifiable?

[Borda]

Regarding the other files (like Detections class in core.py), many examples depend on external libraries like torch, ultralytics, or transformers which are not installed in the default CI environment. Is using # doctest: +SKIP for these imports and model calls the preferred approach in this project, or should we aim for a different way to make them verifiable?

For these, we can create an integration group in pyproject.toml, and in the docstrings, we can have a conditional skip if a dependency is missing... and have one simple CI job which would install all the integration group 🦝

See section "Skip Unconditionally" in the https://pypi.org/project/pytest-doctestplus/ where this would be inside the condition