Feature Request: Native BIP352 support in `hsmd` and enhanced `bcli` block fetching

# Feature Request: Native BIP352 support in `hsmd` and enhanced `bcli` block fetching

## The Issue
I have been developing an experimental/proof-of-concept Core Lightning plugin to introduce BIP352 (Silent Payments) support directly to CLN nodes. You can see the current progress here: [aido/silentpayments](https://github.com/aido/silentpayments/blob/development/README.md).

To get this working as a Python plug-in, I had to make a few compromises that bypass CLN's standard architecture. As a result, the plugin is practically operating as a "shadow wallet" alongside Core Lightning, which is far from ideal. I'm opening this issue to see if it is possible to get native support for these requirements in future releases.

### 1. The `hsmd` derivation bottleneck
Because `hsmd` strictly (and rightly) locks away the master seed, the plugin currently cannot perform the necessary BIP352 ECDH tweaks or natively sign Silent Payment outputs.

**The Workaround:** I am using the `makesecret` RPC (with the tweak `bip352_silent_payments`) to deterministically derive a 32-byte secret, which I then use as the master seed for BIP32 inside the plugin.
**The Consequence:** This creates a non-standard derivation path and forces the plugin to act as a siloed "shadow wallet". If a user takes their 24-word CLN recovery phrase and imports it into a BIP352-compatible wallet (like Sparrow), it will not see these funds. The addresses are completely tethered to the plugin's `makesecret` sandbox, which is a major UX and security risk for users trying to recover funds.

### 2. The `bcli` verbosity limitation
For BIP352 block scanning, we need the `prevout` `scriptPubKeys` for all inputs to calculate the tweaks.

**The Workaround:** I have to use Python's `subprocess` to call `bitcoin-cli getblock 3` directly.
**The Consequence:** I cannot use CLN's internal `bcli` plugin because it is heavily locked down (only exposing 5 hardcoded commands to the RPC) and its internal C code strictly hardcodes `getblock` to verbosity "0" (raw hex). Shelling out to `bitcoin-cli` is brittle and bypasses the node's native architecture.

## Proposed solution
1. **Native BIP352 Support in `hsmd`:** It would be great to see native BIP352 derivation paths, ECDH tweaks, and signing capabilities added to `hsmd` (specifically `libhsmd.c` / `hsm_control.c`). This would allow plugins to request Silent Payment addresses and signatures securely, integrating properly with the main node rather than acting as a disjointed shadow wallet.
2. **Verbosity "3" Support in `bcli`:** Either allow `bcli`'s `getblock` command to accept a verbosity parameter (specifically level 3) so plugins can retrieve full transaction details with `prevout` data, or expose a more flexible RPC pass-through for `bitcoind`.

## Additional context
### Why BIP352 for Core Lightning?
Lightning node operators frequently need to share a static on-chain address; whether for node donations, liquidity management, submarine swaps, or out-of-band channel funding. Currently, doing so may compromise on-chain privacy, as chain surveillance can easily link a public Lightning Node ID to an entire UTXO history.

Bringing BIP352 to CLN allows operators to publish a single, reusable static address that preserves their privacy. Adding native hooks for BIP352 would make it easier for the plugin ecosystem to build out these advanced privacy features without requiring users to run modified C code or risk their funds in sandbox workarounds.