fix: add xmlrpc.php blocking snippet

[ai-anant]

Summary

Adds server-level blocking of xmlrpc.php to mitigate the two well-known XML-RPC abuse vectors in WordPress:

1. Pingback DDoS reflection/amplification (e.g. CVE-2014-5265)
2. Distributed password brute-force via system.multicall against wp-login.php

Changes:

• New standalone snippet htaccess/block_xmlrpc.htaccess (follows the 4-point convention from htaccess/README.md: purpose / vulnerability patched / requirement / conflicts).
• Merged the same block into htaccess/htaccess_full, consistent with how the other standalone snippets (block_access, username_attachment_enumeration, etc.) are included there.

This is consistent with the repo's existing posture: theme_functions/xmlrpc.functions.php disables XML-RPC in PHP and ngnix-config/blocking_wpfiles.nginx already blocks xmlrpc.php — the Apache .htaccess level was the missing piece.

Verification

• Apache 2.4 (Debian 13) apache2 -t: Syntax OK.
• Live request tests against a real Apache instance:
  • GET /xmlrpc.php with standalone snippet → HTTP 403 (AH01797 client denied by server configuration), normal files still 200.
  • With htaccess_full: xmlrpc.php denied (deny logged), no .htaccess parse errors in error log.
• No test suite exists in the repo; CI is Semgrep only (no rules apply to .htaccess content).

Notes

• If you rely on Jetpack / WordPress mobile apps / remote publishing, skip this rule — this is called out in the snippet's comments.
• The forum thread linked in issue more htaccess hacks to add from. #4 (webproworld.com) is no longer reachable (404), so the snippet is based on the canonical hardening references already cited in the repo.

Closes #4