fix(honeypot): route non-existent .php probes through nginx to the trap

nginx's `location ~ \.php$` fastcgi-passed EVERY .php path to php-fpm, which 404'd the classic
attacker probes (/wp-login.php, /xmlrpc.php, /admin.php, /vendor/…/eval-stdin.php) with 'File not
found' BEFORE they could reach the Laravel honeypot route — so those decoys never trapped behind
nginx (the feature tests hit the Laravel route directly, bypassing nginx, and missed this). Add
`try_files $uri /index.php?$query_string` to the php location so a non-existent .php falls through
to the front controller (only index.php actually exists in public/, so nothing else executes).
Verified through nginx: all .php + non-.php + dotfile decoys now serve the deceptive 200.

docker/nginx/nginx.conf

@@ -71,6 +71,12 @@ http {
         error_page 404 /index.php;
 
         location ~ \.php$ {
+            # A .php request that is NOT a real file (e.g. an attacker probing /wp-login.php,
+            # /xmlrpc.php, /admin.php, /vendor/…/eval-stdin.php) must reach Laravel (the honeypot
+            # route) instead of returning php-fpm's "File not found" 404. Only index.php actually
+            # exists in public/, so this executes solely the front controller; every other .php
+            # falls through to /index.php and is routed by the app.
+            try_files $uri /index.php?$query_string;
             fastcgi_pass 127.0.0.1:9000;
             fastcgi_index index.php;
             include fastcgi_params;