fix(aztec-nr): restrict raw note-enqueue sink to pub(crate)

[vezenovm]

Fixes F-832

Reduce enqueue_note_for_validation and NoteValidationRequest from pub to pub(crate). These are only ever called by aztec-nr's own discovery paths, which run nonce discovery before enqueuing so every enqueued note's unique hash is guaranteed present in the tx effects.

Addresses F-832 as API hygiene rather than a security boundary. Two distinct threat models:

1. F-832's actual threat: malicious sender vs honest contract. The honest author uses documented, pub APIs in good faith. A pub raw sink that looks like "the way to deliver a note from a handler" invites them to wire it up, and then any sender could brick others. Removing it from the pub surface means an honest author can't build the vulnerable pattern.
2. Malicious/broken contract author. Unpreventable: they can recompute the slot, push directly, or just panic in a handler. aztec-nr can't and does not need to stop this. The only people harmed are users who chose to run that bad contract, and the blast radius is that one contract's scope.

Maybe we do not even deem this pub(crate) restriction worth it as I do not think custom message handlers have high demand at this point. But it felt easy enough to restrict the API here. If they ever do have large demand perhaps we should think through our APIs a bit further as to help custom message handlers avoid foot-guns. Once custom handlers become more heavily used we could consider APIs that at least push devs towards inclusion being checked or provide boilerplate for safe custom handlers