client: support already-derived file keys

[caniko]

Summary

Add file-backend APIs for callers that already hold derived key material:

• LockedKeyring::{validate_key, unlock_with_key}
• UnlockedKeyring::{load_with_key, open_with_key, open_at_with_key}

This also makes oo7::Key publicly nameable for those APIs.

Behavior

Keys are checked against the active crypto backend's required key length before use.

validate_key mirrors validate_secret: it returns true for an empty keyring or when at least one item authenticates. unlock_with_key retains the existing corruption thresholds, so a partially corrupted keyring can validate but still return PartiallyCorruptedKeyring.

Non-empty unencrypted keyrings reject a direct key. Key-based open and open_at operate only on v1 paths and do not inspect or migrate v0 files; secret-based open retains legacy migration.

An exact-length Key::new(...) value is treated as caller-supplied direct key material, so the caller is responsible for its entropy.

Scope

This PR does not add restart state, fdstore transport, PAM or server changes, D-Bus readiness changes, migration recovery, a generic credential provider, or an unchecked key API.

Testing

Tested with both crypto backends, the complete Tokio client suites, async-std builds, workspace checks and clippy, rustfmt, rustdoc, cargo-deny, and the affected server and package builds. A disposable external async-std consumer also exercised key-only read, write, reload, and wrong-key rejection with both crypto backends without Tokio or oo7-daemon in its feature graph.

Refs #548.

[github-actions]

📊 Code Coverage Report

Metric	Value
Current PR Coverage	83.44%
Main Branch Coverage	83.39%
Coverage Change	📈 +0.05%

Coverage report generated by cargo-tarpaulin

[caniko]

Addressed the five review comments in fa4b0dc; the follow-up checks are green. Ready for another look.

[bilelmoussaoui]

thanks!