Outdated Example Lifecycle Architecture

## Problems
Currently the testing systems rely on unit tests or simple import checks. While these methods verify that code
executes without syntax errors, they do not ensure that example applications are fully operational in a real runtime
environment. As a result,
several critical issues can remain undetected, including:

- P1: Missing dependency detection for examples
- P2: Dependency installation failures going unnoticed
- P3: Dependency conflicts caused by shared environments
- P4: Example applications failing during startup
- P5: Example processes exiting early without clear reporting
- P6: CI pipelines hanging due to stalled or infinite-running examples
- P7: Server boot failures in interactive simulations
- P8: Non-responsive example servers after launch
- P9: Missing or invalid run commands for examples
- P10: Undetected usage of deprecated or removed Mesa APIs
- P11: Port conflicts and leftover processes affecting subsequent tests
- P12: Lack of structured validation reports for debugging and maintenance
- P13: No, operational validation that ensures examples are actually runnable in a real environment

For interactive simulation frameworks such as Mesa, correctness cannot be determined solely through static execution
checks. A meaningful testing strategy must validate that examples can start, run, and expose their simulation
interfaces under real runtime conditions. Otherwise, examples may pass CI tests while remaining unusable in practice.

## Solutions
### 1.User-Experience-Oriented Validation
The proposed system focuses on runtime validation rather than static checks. Each example is executed as a running
application, its runtime behavior is monitored, and its visualization server is verified through HTTP requests. This
approach ensures that validation reflects the real user experience, and unit tests for examples are also executed
during the example’s launch.
Problem addressed :P4,P5, P7,P8

### 2.Dual Validation System
My intention is very simple.
i.e. Examples should run reliably with their declared dependencies, but it is also important to detect whether updates
to Mesa or related libraries introduce compatibility issues.
To support this approach, I have developed a dual validation system that tests examples in two environments:
- Validator 1 — Latest environment validation
- Validator 2 — Declared environment validation
These are two python testing scripts which will validate examples via CI.
Problem Addressed : P1,P2,P3,P6,P9,P10,P11,P12,P13

### I've already completed the most crucial parts of the solutions part — both validators (latest env + declared env) are working, all 21 examples have been audited, and the CI workflow is planned out. I'm genuinely ready to complete this.

- The prototype is ready , have a look and tell me if i should start making PR's
Prototype: https://github.com/Tushar1733/mesa-examples

Start by reviewing the two Python validation scripts described in the proposal and the linked prototype repository, then compare their behavior with the planned CI workflow. Confirm how all 21 examples are launched, isolated, monitored, and reported in both latest and declared environments; done means runtime failures, dependency issues, hangs, server problems, and invalid commands are detected clearly in CI.

Written by the indexing model from the issue text.