fix: answer 404 for WordPress content directories

[ogorzalka]

Problem

Fixes Pollora/framework#294.

WordPress ships an empty index.php ("Silence is golden") in wp-content, wp-content/plugins and wp-content/themes. With public/cms/wp-content/ under the document root, Apache served it directly:

URL	Before
/cms/wp-content/, /cms/wp-content/index.php, /cms/wp-content/plugins/, /cms/wp-content/themes/	200, empty body
/content/, /content/plugins/, /content/uploads/	403

Either way a visitor learns the directory exists. #187 removed content/plugins/index.php, which turned that one into a 403; the core files cannot be removed from the skeleton.

These requests never reach Laravel (Apache runs the stub index.php itself), so the framework middleware the issue suggested could not intercept them: the fix belongs to the web server configuration.

Fix

A rule in public/.htaccess, before the trailing-slash redirect: under cms/wp-content and content, a directory or an index.php goes to the front controller, which answers with the site's own 404. Files in those directories (plugin CSS/JS, uploads) are served as before.

Tests

New install check group 1.9 — Content directories answer 404 (php tests/install/run.php checks directories), run in the web and artisan scenarios: each path above must render the site's 404 page, and a core and a plugin stylesheet must still answer 200.

Measured on pollora-test (DDEV, apache-fpm): 8/8 with the rule, 7 failures without it (blank 200s and 403s). Also checked by hand: a WooCommerce stylesheet, an upload, a Vite build file, wp-login.php, wp-admin/, the home page and the shop are unaffected.

Nginx is not covered by this file; server-configuration.md will be updated with the release.