Implement token validation from APNs responses

Summary by opus 4.8:

 ApnsPhpMessagingApi::validateToken() is a stub: it throws on an empty/whitespace
 string and otherwise returns TRUE for every non-empty token
 (dev/apns_php/src/Service/ApnsPhpMessagingApi.php:142). The unit test
 testValidateTokenAcceptsNonEmpty codifies that stub as correct. The
 log_token_validation_result config key is never read, and
 ApnsPhpInvalidTokenException is unused.

 Why no probe: unlike FCM (which firebase_php validates via
 validateRegistrationTokens), APNs has no pre-validation endpoint (confirmed
 against Apple's docs + the Pushok README). A token's validity is only knowable from
 the response to a real send (getStatusCode() / getErrorReason()). Apple's
 guidance: stop using tokens that return Unregistered / BadDeviceToken /
 DeviceTokenNotForTopic; treat 403 (Forbidden / ExpiredProviderToken — these are
 auth/JWT, not device-token, problems), 413, 429, and 5xx as transient and keep
 the token.

Summary of implementation:

 dev/apns_php — validateToken is now a real classifier

  - src/Service/ApnsPhpMessagingApi.php: validateToken(ApnsResponseInterface): bool — 200→true;
  410/400-BadDeviceToken/DeviceTokenNotForTopic→false; everything else throws a categorized exception via match. Wired
  log_token_validation_result (redacted, hashed-token logging via new hashTokenForLog). Moved the empty-token guard into
  sendMessageMultipleDevices.
  - src/Exception/: new ApnsPhpAuthenticationException (403), ApnsPhpPayloadException (400-non-token/413),
  ApnsPhpServerException (429/5xx) — all extend ApnsPhpException.
  - src/ApnsPhpMessagingApiInterface.php: signature + docstring rewritten (the wrong "Google's servers" text is gone;
  documents the throw contract).
  - Tests: replaced the three stub tests with response-driven cases (200/410/400-bad/400-not-for-topic, 403→auth,
  413→payload, 429/503→server, redaction-on/off) and relocated the empty-token assertions to the send path.