feat(notary): support bounded target attributes in consultations

[jeremi]

Summary

• allow Relay consultation inputs to map an explicitly named request.target.attributes.<stable-name> value
• preserve supported string, Boolean, and integer target attribute types through project fixtures, Notary evaluation, and the Relay JSON request
• keep target IDs and identifiers string-only
• document the bounded mapping grammar and clarify that target attributes are caller-supplied, not authenticated by the mapping

This is generic Registry Stack support. It does not add an OpenCRVS-specific example or modify lab/.

Security boundary

• mappings must name one target attribute explicitly using the stable-name grammar [a-z][a-z0-9_]{0,63}
• mappings cannot traverse arbitrary target object paths
• null, object, array, floating-point, and unsupported request values fail before consultation execution
• the verified Relay contract controls whether a supported value is encoded as a JSON string, Boolean, or integer
• non-canonical Boolean and integer values fail before the network request

An authored mapping admits a caller-supplied value. It does not authenticate that value.

Verification

• cargo fmt --all --check
• cargo clippy --locked -p registry-notary-server -p registryctl --all-targets -- -D warnings
• cargo test --locked -p registry-notary-core
• cargo test --locked -p registry-notary-server
• cargo test --locked -p registryctl
• npm test in docs/site
• npm run check in docs/site, including current and archived documentation builds, SEO checks, and built-link validation

The branch is rebased directly onto the current main.