Ntx Builder: replace dataless `Notify`

[SantiagoPittella]

As talked with Mirko on slack:

We previously swapped to notify + chain tip + db for comms. Which I think is okay. But we can probably do better.

Some examples:

• instead of chain tip watcher, have a watcher for the full block
  actors which are waiting for a tx monitor this until the tx expires or the block contains the tx
  so no db scan required for the tx ID

• we could also assume that the tx succeeds and try build more
  and only revert if the rpc service responds with the state commitment mismatch
  and then roll back to that tx

Currently the data for the first idea already reaches the builder, the only thing missing is the last hop: Coordinator::handle_committed_block wakes every actor with a dataless Notify, so each actor then queries the DB (account_last_tx, select_candidate) to figure out what happened.

We can use a per-actor AccountView over a watch channel and replace the Notify with a tokio::sync::watch::channel<AccountView> and have the coordinator build a targeted cumulative update per account like:

pub struct AccountView {
    chain_tip: BlockNumber,
    committed_txs: Vec<(TransactionId, BlockNumber)>,
    // monotone "new notes seen since spawn" counter, etc.
}

watch is the right primitive because an actor can spend several blocks inside execute/prove. Watch overwrites unread values, which is fine here because every field is will be cumulative: an actor waking after 10 blocks reads the latest view and can still answer "did my tx land in any block since submission" (membership in committed_txs), "has it expired" (tip vs submission block), and "is there new work" (counter vs a local cursor) entirely in memory.

[Mirko-von-Leipzig]

Interesting, I hadn't considered an aggregate watch channel before. That's a neat pattern.

A concern: committed_txs: Vec<(TransactionId, BlockNumber)> - that needs to be pruned, or kept constant size somehow. Perhaps it could also be a simple counter txs_committed: usize.