Support optional limit parameter in NTL fetch_notes

## Context

The Note Transport Layer (NTL) now supports an optional `limit` field on `FetchNotesRequest` ([0xMiden/note-transport-service#84](https://github.com/0xMiden/note-transport-service/pull/84)). This lets clients request smaller pages instead of always receiving up to 500 notes per call.

```protobuf
message FetchNotesRequest {
repeated fixed32 tags = 1;
fixed64 cursor = 2;
// Maximum number of notes to return. When unset the server applies its
// own batch cap (currently 500). Values above the server cap are clamped.
optional uint32 limit = 3;
}
```

## Proposed client changes

The `miden-client` calls `fetch_transport_notes` during sync. Currently it sends `FetchNotesRequest` without a `limit`, receiving up to 500 notes per call. The client should:

1. **Pass through the limit field** in the NTL gRPC client code. No behavioral change needed if `limit` is left unset - the server default (500) applies.

2. **Consider setting a limit for constrained environments.** Browser extensions (service workers) and mobile wallets that sync every few seconds may benefit from requesting smaller batches (e.g. 10-50 notes) to keep each response lightweight. This could be a configuration option on the client.

3. **Proto update.** Regenerate the NTL proto bindings in the client to pick up the new `limit` field. The field is `optional`, so the client compiles without changes - but it can't use the feature until the bindings are regenerated.

## Priority

Low. The existing behavior (no limit, server caps at 500) works fine for most clients. This is primarily useful for constrained environments that poll frequently.

Relates to [0xMiden/note-transport-service#46](https://github.com/0xMiden/note-transport-service/issues/46) and [0xMiden/note-transport-service#4](https://github.com/0xMiden/note-transport-service/issues/4).