cuprated: Add graceful shutdown, pt2: service error propagation

[redsh4de]

What

Depends on pt1, PR #585

Building on part 1, this replaces the panic-on-error patterns in cuprated's services with error propagation that makes use of the graceful shutdown mechanism

Why

So we dont panic and insta-crash upon a error, shutdown should be graceful. Internal errors still caused panics before this via PANIC_CRITICAL_SERVICE_ERROR

Where

• cuprated
  • Base
    • monitor.rs - added spawn_critical to TaskExecutor, which logs errors and triggers shutdown on task end
    • constants.rs - removed PANIC_CRITICAL_SERVICE_ERROR
  • Blockchain
    • manager.rs - use spawn_critical for syncer and manager tasks
    • handler.rs - replace all .expect(PANIC_CRITICAL_SERVICE_ERROR) with ?/.map_err(), add HandleBlockError enum to distinguish validation errors from service errors, functions return anyhow::Result
    • interface.rs - add IncomingBlockError::Service variant, replace .expect() with .map_err()
    • syncer.rs - suppress IncomingBlockChannelClosed error if shutting down
    • blockchain.rs - check_add_genesis returns anyhow::Result
  • Txpool
    • manager.rs - same expect to ? pattern, spawn_critical, functions return anyhow::Result
    • incoming_tx.rs - add IncomingTxError::Service variant, error handling for incoming tx path
  • P2P
    • request_handler.rs - add HandlerError enum (Peer vs Service), replace expect with typed error propagation, log service errors
  • RPC
    • server.rs - spawn to spawn_critical with ? propagation
    • json_rpc.rs - handle IncomingBlockError::Service in submit_block, trigger shutdown
    • other_json.rs - pass shutdown token to tx handler
    • tx_handler.rs - handle IncomingTxError::Service, trigger shutdown

How

spawn_critical wraps each subsystem's future: if it returns an error it is logged and the shutdown token is hit, triggering the same graceful shutdown path as OS signals.

Critical tasks returning Ok(()) also trigger shutdown.

Validation errors (invalid blocks/transactions from peers) are distinguished from service errors (database/internal failures) using simple enums (HandleBlockError, HandlerError). Only service errors propagate to shutdown - validation errors are handled gracefully (ban peer, cancel downloader, etc.)