aead: support Encrypt for ProtectedRef<T> #561

vitaminc_aead::plaintext::Encrypt supports Protected<T> and &Protected<T>, but not ProtectedRef<'a, T>. This prevents callers from passing an AsProtectedRef borrow directly into the plaintext visitor.

Confirmed in the published 0.8.0 sources and the current default-branch plaintext sources. ProtectedRef keeps its inner reference private to vitaminc-protected, so downstream code cannot implement a transparent adapter over that borrow either.

Minimal example

With vitaminc-aead and vitaminc-protected 0.8.0:

use vitaminc_aead::plaintext::Encrypt;
use vitaminc_protected::{AsProtectedRef, Protected};

fn accepts_source<S: Encrypt>(_: S) {}

fn main() {
    let value = Protected::new(42i32);
    accepts_source(&value);                    // supported
    accepts_source(value.as_protected_ref());  // missing Encrypt implementation
}

Downstream use case

Stack Encrypt #1404 consumes owned plaintext, holds it in Protected, and synchronously plans encryption through a borrow. We would like to carry a protected borrow through that boundary.

For now, the declaration boundary receives a reference via risky_ref(), and a local ScalarRef bridge implements Encrypt while forwarding the underlying encoder's DEPTH and FIXED metadata. Native protected-borrow support would let us revisit this workaround.

Requested behavior

• Support Encrypt for ProtectedRef<'a, T> when &'a T: Encrypt, including unsized sources where supported.
• Preserve the underlying borrowed encoder's DEPTH, FIXED, scalar kinds and visitor behavior. In particular, preserve typed-null padding for fixed-width nullable values.
• Walk the existing borrow without adding a Clone requirement or copying an owned plaintext buffer. Wiping remains the owner's responsibility; consuming the borrow must not imply that it wipes the owner.
• Keep access to the inner reference controlled. The implementation needs a deliberate bridge between vitaminc-protected and vitaminc-aead; this is not a request for unrestricted public Deref or inner-reference access.

Validation should cover the example above, scalar/string/container visitor parity with &Protected<T>, fixed-width Some/None sealed-length parity and successful opening, and owner cleanup after successful and failed walks.

Related: Stack #1468 tracks secure Buffer adoption after #559 and notes this protected-borrow gap. This issue tracks the Encrypt capability separately.