Support attachment-based filtering in SyncNotes (tag + attachment subscriptions)

## Summary

Today a client can only subscribe to **note tags**. The node returns every note in a
block range matching a subscribed tag, and the client filters locally — discarding notes
it doesn't need. This wastes bandwidth: the node ships notes the client immediately
throws away.

Proposal: let a client subscribe to a **tag *plus* an attachment filter**. The node
matches by tag (as today), then applies the attachment filter, and forwards only what
passes both. Tag stays the coarse category; attachment becomes an indexed, filterable
topic.

Based on [rust-sdk#2209](https://github.com/0xMiden/rust-sdk/issues/2209)

## Background

Tags are coarse and collision-prone (a truncated prefix), so many unrelated notes share
one. A particular client has to download all the notes for the particular tag and filter it out itself.

## Motivating case: PSWAP

A PSWAP chain shares **one constant tag** across all descendants. Under tag-only
subscription, a creator receives *everyone's* partial fills for that asset pair, then
keeps only the serials matching their own chain. But the discriminating data is already
in the attachment (P2ID `fill_amount` at slot 0), and the creator can derive exactly
which note ids / attachment words are theirs. An attachment filter lets the node drop
everyone else's traffic before it leaves the server. Pairs naturally with
[#2157](https://github.com/0xMiden/node/issues/2157) (plain-word attachments the node can
filter on directly).

## Analogy: EVM logs

tag ≈ contract address · attachment ≈ indexed topics · `{tag, attachment_filter}` ≈
`{address, topics}`. A filtered event stream instead of "everything from this contract".

## Open questions

- **Node vs. sidecar** — node owns cheap exact-match; a dedicated indexer owns richer
queries and scaling. Where's the line?