fix : prevent reflected XSS by encoding var_export() output

[g0w6y]

All 6 example files reflect unsanitized POST data and response objects
directly into HTML via var_export() with no encoding, allowing reflected
XSS via the g-recaptcha-response parameter.

PoC :

curl -X POST https://recaptcha-demo.appspot.com/recaptcha-v2-checkbox.php \
  --data-urlencode 'g-recaptcha-response=</pre><img src=x onerror=alert(document.domain)>'

Root cause:
var_export($_POST) and var_export($resp) write user-controlled data into
HTML with zero encoding. No htmlspecialchars() exists anywhere in examples/.
The </pre> in the payload breaks out of the tag and the browser executes
the injected script.

Fix:
Replaced all var_export() calls with:
htmlspecialchars(print_r(..., true), ENT_QUOTES | ENT_HTML5, 'UTF-8')
across 6 files, 18 lines total. No logic changes.

Files changed:

• examples/recaptcha-v2-checkbox.php
• examples/recaptcha-v2-checkbox-explicit.php
• examples/recaptcha-v2-invisible.php
• examples/recaptcha-request-curl.php
• examples/recaptcha-request-post.php
• examples/recaptcha-request-socket.php

These files are actively deployed on recaptcha-demo.appspot.com and widely
copied by developers into production insecure patterns here propagate
directly into real applications.

[rowan-m]

I don't have tests that run the demos (yet... I suppose I really should set up an e2e suite) so l will need to test this locally before merging.