Add AdminClient::createSnapshot() and forceRecoveryWithDataLoss() (direct C API)

[s2x]

Description

Two disaster-recovery entry points from fdb_c.h are not bound in NativeClient.php:

FDBFuture* fdb_database_create_snapshot(FDBDatabase* db,
    uint8_t const* uid, int uid_length,
    uint8_t const* snap_command, int snap_command_length);
FDBFuture* fdb_database_force_recovery_with_data_loss(FDBDatabase* db,
    uint8_t const* dcid, int dcid_length);

AdminClient::forceRecovery() (src/AdminClient.php:282) currently implements force recovery by writing to the special key \xff\xff/management/force_recovery. That path works, but it is not the same entry point the other bindings use, and it inherits the unvalidated-special-key concerns tracked in #43. There is no equivalent at all for create_snapshot, which is how the fdbcli snapshot disaster-recovery flow is driven.

What needs to be done

1. Bind both functions in NativeClient.php.
2. Add to AdminClient.php:
   • createSnapshot(string $uid, string $snapCommand): void — $uid must be a 32-character hex UID; validate it before passing it through.
   • forceRecoveryWithDataLoss(string $dcId): void — the direct C API call.
3. Decide what happens to the existing special-key forceRecovery(): either reimplement it on top of the C call, or keep both and document the difference. Reimplementing is preferred — it removes one unvalidated special-key write.

Notes

• create_snapshot is destructive/operational and requires snapshot support to be configured on the cluster; the integration test needs to be guarded or skipped by default.
• Data loss is in the name of the second call — the docblock must say so plainly.

Acceptance Criteria

• Both C functions bound
• AdminClient::createSnapshot() with UID validation
• AdminClient::forceRecoveryWithDataLoss() implemented
• Existing forceRecovery() either reimplemented on the C call or documented as distinct
• Integration tests (guarded where destructive)
• docs/admin.md updated
• composer lint and composer test clean

[s2x]

Implemented in PR #106.

• Both C functions bound in NativeClient (fdb_database_create_snapshot, fdb_database_force_recovery_with_data_loss).
• AdminClient::createSnapshot(uid, snapCommand) added with 32-hex-char UID validation and printable-ASCII command validation.
• AdminClient::forceRecoveryWithDataLoss(dcId) added (token allow-list validation); the existing forceRecovery() was reimplemented on the C call rather than kept as a special-key write — it is now a working alias of forceRecoveryWithDataLoss() and no longer throws LogicException. This removes one unvalidated special-key write path flagged in [Security] AdminClient writes unvalidated input into privileged special keys; several special-key paths unverified #43.
• Destructive happy-path integration tests live in tests/Integration/AdminDestructiveOperationsTest.php, skipped unless FDB_ENABLE_DESTRUCTIVE_ADMIN_TESTS=1.
• docs/admin.md and CHANGELOG.md updated; composer lint and composer test clean.