test: switch to a classic fixture theme instead of assuming one (#145)

[ifahimreza]

Closes #145

What

The classic-theme playbook test now switches to a classic fixture theme instead of assuming the host WordPress runs one. A block-theme fixture variant is pinned alongside it, so both branches of step 2 are tested on every machine.

Why

test_the_playbook_adapts_step_two_to_a_classic_theme has been red on every CI run since 2026-08-21, on all six matrix legs, while green locally. The test's own comment said "the test site runs a CLASSIC theme". That was an environment fact, not a fixture: the harness symlinks wp-content/themes from the host install, which on the developer's machine is a classic theme. CI provisions a fresh core whose bundled themes are all block themes, so wp_is_block_theme() was true and the playbook rendered the block-theme step 2.

How

• New tests/fixtures/themes/saddle-classic-fixture/ (style.css + index.php). Its index.php and the absence of templates/index.html + theme.json are what make wp_is_block_theme() return false.
• New with_theme() helper in skills-test.php, mirroring the register/switch/restore pattern site-editor-test.php already uses. Both classic-theme tests go through it; each asserts the fixture reads as the theme type it means before checking the playbook.
• New test_the_playbook_sends_step_two_to_the_template_parts_on_a_block_theme pins the other branch, using the existing saddle-block-fixture. Passing on the developer's classic host proves the switch works in the direction CI needs.
• No production code changed.

Testing

• composer lint — 0 errors, the 3 pre-existing warnings
• composer test — 654 tests (was 653), 1 pre-existing skip, locally
• CI green on all six legs — the actual fix is only proven there