[auto-rotation feature] feat: add key auto-rotation specification + manual rotation for all key types

[Manuthor]

Summary

Delivers the complete key auto-rotation specification and the full manual-rotation
implementation for all key types.

This is PR 1 of 4 in the key auto-rotation feature stack:

develop
  ← PR 1  docs/key-autorotation-spec          ← this PR (#968)
  ← PR 2  feat/key-rotation-ckms-ui            (#988)
  ← PR 3  feat/key-rotation-scheduler          (#970)
  ← PR 4  feat/key-rotation-notifications      (#971)

What's included

Documentation

• Full rotation-policy attribute table (x-rotate-interval, x-rotate-name,
  x-rotate-offset, x-rotate-generation, x-rotate-date)
• Seven rotation scenarios with Mermaid diagrams: plain key, wrapping key,
  wrapped key, asymmetric key pair, wrapped private key (CoverCrypt),
  certificate renewal (ReCertify), server-wide KEK
• KMIP link chain after successive rotations (ReplacementObjectLink /
  ReplacedObjectLink)
• Attribute update table for auto-rotation vs manual rekey (intentional asymmetry)
• Server-side scheduler configuration reference
• HSM-resident key limitation note
• Step-by-step end-to-end configuration guide

Implementation — Re-Key, Re-Key Key Pair, Re-Certify

Complete manual-rotation implementation for all six scenarios:

1. Plain symmetric key — new material, new UID, rotation metadata
2. Wrapping key — rotate + re-wrap all dependants (two-phase commit)
3. Wrapped key — unwrap → new material → re-wrap
4. Asymmetric key pair — new private key + new public key UIDs, all curve types
   (RSA, EC, ML-KEM, ML-DSA, SLH-DSA, X25519, secp256k1, CoverCrypt)
5. Wrapped private key / CoverCrypt — CoverCrypt rekeying with wrapping preserved
6. Server-wide KEK — transparent via default wrapping config

Implements ReCertify (KMIP 2.1 §6.1.45) for certificate renewal:

• Self-signed and CA-signed renewal
• Replacement link chain management (ReplacedObjectLink / ReplacementObjectLink)
• Offset-based PreActive state for future-activation certificates

All 344 test vectors pass.

Breaking changes

None.

Reviewer notes

This document is the canonical reference for all subsequent PRs in this stack.
Please review terminology and attribute semantics carefully; changes here will
cascade to the implementation PRs.

[Copilot]

Pull request overview

This PR is the first in the key auto-rotation feature stack. It introduces the canonical auto-rotation specification document and lands the underlying manual rotation implementation for keys and certificates (ReKey, ReKeyKeyPair, ReCertify), plus the database plumbing and test vectors needed for wrapping-key dependant rewrites and certificate renewal link chains.

Changes:

• Add comprehensive documentation for rotation policy attributes, scheduler semantics, and rotation/renewal scenarios (with diagrams and attribute tables).
• Refactor and extend server KMIP operations to implement manual rotation flows for symmetric keys, key pairs, and certificate renewal (ReCertify) using a shared orchestration trait.
• Add ObjectsStore::find_wrapped_by() across SQL backends to support wrapping-key rotations that must re-wrap dependants, and extend test vectors/runner docs accordingly.

Reviewed changes

Copilot reviewed 35 out of 35 changed files in this pull request and generated 16 comments.

Show a summary per file

File	Description
README.md	Adds a documentation link for scheduled key auto-rotation.
documentation/mkdocs.yml	Registers the new Key Auto-Rotation documentation page in the nav.
documentation/docs/kmip_support/key_auto_rotation.md	Adds the full auto-rotation specification and scenarios (policy attributes, flows, roadmap).
crate/test_kms_server/src/vector_runner.rs	Registers new negative and positive vectors for ReCertify and offset state verification.
crate/test_kms_server/README.md	Updates vector counts and documents newly added vectors.
crate/server/src/core/wrapping/wrap.rs	Tightens self-wrap handling and bypasses KEK ownership checks for server-wide KEK.
crate/server/src/core/operations/rekey/*	Introduces a new rekey/ module with shared orchestration + symmetric/keypair flows.
crate/server/src/core/operations/recertify.rs	Adds server-side ReCertify implementation and dependant relinking behavior.
crate/server/src/core/operations/{mod.rs,message.rs,dispatch.rs}	Wires ReCertify through dispatch and operation processing.
crate/server/src/core/operations/key_ops/mod.rs	Fixes lifecycle setup so PreActive objects retain a future activation_date.
crate/server/src/core/operations/certify/*	Broadens visibility of certify helpers/types for reuse by ReCertify.
crate/server/src/core/kms/kmip.rs	Adds the KMS::recertify entry point.
crate/interfaces/src/stores/objects_store.rs	Adds find_wrapped_by() to the store trait (default empty).
crate/server_database/src/core/database_objects.rs	Exposes Database::find_wrapped_by() across backends.
crate/server_database/src/stores/sql/{sqlite,pgsql,mysql}.rs	Implements find_wrapped_by() using JSON queries in each SQL backend.
crate/kmip/src/kmip_2_1/{kmip_operations,kmip_messages}.rs	Adds KMIP 2.1 ReCertify request/response types + message (de)serialization.
crate/kmip/src/kmip_1_4/kmip_operations.rs	Adds 1.4↔2.1 conversions for ReCertify types and operation mapping.
CHANGELOG/feat_key-rotation-manual.md	Adds the required branch-specific changelog for manual rotation changes.
CHANGELOG/docs_key-autorotation-spec.md	Adds the required branch-specific changelog for the spec doc addition.

[tbrezot]

I could not go through all diffs, but thanks to your documentation I could grasp enough of the idea to have a few questions (cf my comment of the doc). I will complete the review once we have discussed those points.

[tbrezot]

A lot of effort has been put into this MR, and it greatly improves the initial implementation. I still have a few comments though:

• a few nitpicks that are trivial to correct;
• maybe an issue concerning the key-selection procedure;
• some deeper concerns about concurrency management, which are orthogonal to this feature and may be addressed in a dedicated MR.

Also, since it is structuring, it might gain from requesting a review from someone else. In any case, I may spend more time on it if you delay the merge (since it is huge, I could not read everything).