The integration suite shares one `Table_Dumper` across every test file

[TBarregren]

This was generated by AI during triage.

Split out of #33 at triage. #33 chose to make the table-catalog memo self-correcting rather than to fix the harness, on the grounds that the harness hazard is real but is not the price of recovering a hundred redundant round trips per table. This is that hazard, on its own.

Agent Brief

Category: enhancement
Summary: Stop the integration suite sharing one Table_Dumper across every test file.

Current behavior:
tests/Integration/bootstrap.php requires every test file into a single PHP process, and classes/Plugin.php constructs one Table_Dumper for the whole suite. Every test file therefore shares one instance, and any state that instance accumulates leaks between files that have no relationship to each other.

This is not hypothetical: it is precisely what caused plan 007 to drop its step (c). A per-request catalog memo — correct in production, where a request is short-lived and a Table_Dumper does not outlive it — went stale across a suite-long instance and hid fixture tables created by later test files. The plan was abandoned rather than the harness fixed.

Desired behavior:
A test file gets an instance whose lifetime matches what production would give it, so per-request state means per-request in the tests too. A test file cannot observe state another test file left behind, and a change that is correct for a real request cannot be made to look wrong by the harness.

The shape is the agent's call — a fresh instance per file, an explicit reset between files, or restructuring how Plugin wires the dumper for tests — provided the observable property holds: suite-long shared state is gone, and the suite still runs in one process. Do not convert the suite to one process per file; the single process is deliberate and is what makes the suite fast.

Key interfaces:

• The integration bootstrap's file-loading loop and whatever it constructs before the first file runs
• How Plugin wires a Table_Dumper, and whether the tests should be going through Plugin for it at all
• Any other suite-long singleton with per-request semantics in the same construction path — if one is found, name it in the changelog entry even if it is left alone

Acceptance criteria:

• No Table_Dumper instance is shared across integration test files
• A test demonstrates the property directly: state established in one file is not visible to another
• The suite still runs in a single PHP process
• Test runtime does not materially regress — if it does, say by how much and why
• Existing tests pass without being rewritten to accommodate the change; a test that has to change should be a test that was relying on the leak, and that fact belongs in the changelog entry
• CHANGELOG.md carries an Unreleased entry
• composer gate exits 0, with the exit code captured on its own line

Out of scope:

• The catalog memo itself — that is Plan 007's dropped step (c): the per-request table-catalog memo needs its own plan #33, which is written to be correct with or without this change. Neither ticket may be made to depend on the other
• Changing production wiring for any reason other than making the test lifetime honest
• Converting the suite to one process per test file

[TBarregren]

Recorded by an unattended run: built and then verified independently against this ticket's acceptance criteria.