MAINT: Make the slow marker effective; reconsider wall-clock assertions in the unit suite

Problem

pytest.ini defines a slow marker and three tests carry it, but CI runs pytest quantecon with no -m filter, so the marker has no effect anywhere — documentation of an intent that was never wired up.

Two of the three marked tests — test_gridtools.py::test_performance_C and ::test_performance_F — are wall-clock performance assertions, together roughly 15 seconds of the suite. Timing assertions on shared CI runners are a well-known flakiness source, and the project has already had to de-flake timing tests once (#846).

Two things to decide

1. Should CI deselect slow on the pull-request path and run the full suite on merge to main? Cheap, and makes the marker mean something.
2. Do wall-clock assertions belong in a correctness suite at all? If the intent is to catch performance regression, a benchmark job comparing against a baseline is the tool; a unit test that fails when a runner is busy is not.

Acceptance criteria

• A decision recorded on where slow tests run, and CI matches it
• test_performance_C/test_performance_F converted to relative benchmarks, given meaningful tolerances, or removed with their intent documented
• The slow marker either affects selection somewhere, or is removed from pytest.ini

From the July 2026 technical-debt audit (AI-assisted; claims verified against 28d4b3b on 2026-07-25).

Start with pytest.ini, the CI configuration, and quantecon tests test_gridtools.py::test_performance_C and test_performance_F. Determine how the slow marker should affect pull-request and main-branch runs, then resolve the timing-test approach and update selection or marker configuration. Done means the acceptance criteria are met and the suite behavior is documented by tests or configuration.