Smart Contract Diff Audit L-27: P2ID and P2IDE Conversions Ignore Recipient Note Tag Length Preference

An `Address` carries a note tag length routing parameter through which the receiver states how many bits of its account ID prefix should be encoded into the tags of notes sent to it. The [`address.md`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/docs/src/account/address.md?plain=1#L99-L101) documentation describes this value as the tag length that the sender is expected to create, and the type exposes it through [`note_tag_len`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/crates/miden-protocol/src/address/mod.rs#L108-L113) and [`to_note_tag`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/crates/miden-protocol/src/address/mod.rs#L116-L126).

The conversions of the standard payment notes into protocol notes do not honor that preference. Both [`From for Note`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/crates/miden-standards/src/note/p2id.rs#L201-L209) and [`From for Note`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/crates/miden-standards/src/note/p2ide.rs#L224-L232) derive the tag with [`NoteTag::with_account_target`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/crates/miden-protocol/src/note/note_tag.rs#L83-L86), which always applies the default length of 14 bits, and the builders accept only an account ID as the [`target`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/crates/miden-standards/src/note/p2id.rs#L74-L75), so no routing preference can be threaded through them. A receiver that advertises a length other than the default and filters incoming notes on the exact tag derived from its own address does not match P2ID or P2IDE notes produced by these conversions, and a receiver that selects a shorter length for privacy has 14 bits of its account ID prefix published in note metadata instead of the number it chose. The consequences are limited to off-chain note discovery and to the unapplied privacy preference, since the tag plays no part in authorizing consumption, which is gated by a comparison against the target account ID held in the note storage. No code in the repository reads an `Address` when building a note, so the mismatch arises only for integrators that derive their sync tags from addresses.

Consider threading the recipient `Address` (or an explicit tag length) through the `P2idNote` and `P2ideNote` construction and conversion APIs and deriving the tag with [`NoteTag::with_custom_account_target`](https://github.com/0xMiden/protocol/blob/8411bf093bde25285708faac152b6d7269009617/crates/miden-protocol/src/note/note_tag.rs#L96-L111), so that the advertised length is preserved in the resulting note. Where accepting an `Address` is not intended at this layer, consider documenting that these conversions always emit the default account target tag and exposing a supported way to set the tag explicitly.

---

_Copied verbatim from finding [L-27](https://audits.openzeppelin.com/miden/miden-01-07-smart-contract-diff-audit-nfts/issues/p2id-and-p2ide-conversions-ignore-recipient-note-tag-length-preference-a701c1b4) (low severity) of the OpenZeppelin [smart contract diff audit (NFTs)](https://audits.openzeppelin.com/miden/miden-01-07-smart-contract-diff-audit-nfts). The audit was performed against commit `8411bf093bde25285708faac152b6d7269009617`._