fix(protocol): derive the xattr digest length from the hasher

[oferchen]

MAX_XATTR_DIGEST_LEN was a bare 16. Upstream does not write a number
there: xattrs.c:48 defines it as MD5_DIGEST_LEN, and lib/md-defines.h:12
sets that to 16. The value was right; the construction was fragile — the buffer
bound and the hasher that fills it had no relationship a compiler could check.

It is now derived from the hasher itself:

pub const MAX_XATTR_DIGEST_LEN: usize = <Md5 as OutputSizeUser>::OutputSize::USIZE;

compute_xattr_checksum runs Md5, so the buffer and the digest cannot
disagree by construction.

The distinction the derivation has to preserve

Upstream pins this to MD5's length specifically, not to MAX_DIGEST_LEN
(lib/md-defines.h:13-21, up to SHA-512's 64). compat.c:835-836 fixes
xattr_sum_nni to the implied MD5 choice, above a comment reserving the right
to make the algorithm negotiable later. Deriving from "the longest digest oc can
produce" would have been a wire-format change, not a cleanup — the abbreviated
xattr digest is a wire field.

A const assertion pins the value at 16 so the derivation cannot drift into a
protocol break, and digest_len_is_upstream_md5_digest_len_not_max_digest_len
pins the distinction itself.

Tests

• digest_len_tracks_the_hasher_that_fills_the_buffer — drives the expected
  length from a live Md5::digest(DATUM).len() rather than restating 16, so
  it fails if the constant is ever re-pointed at a different hasher.
• digest_len_is_upstream_md5_digest_len_not_max_digest_len — encodes why 16
  and not 64.

Footprint

One file, +48/-2. No behaviour change: the value is identical before and after.