rpc: avoid exposing all modules over IPC by default

### What IPC is enabled by default and currently installs all RPC modules via `RpcModuleSelection::default_ipc_modules()`. That function returns all modules, which means the default IPC socket exposes sensitive namespaces such as `testing`, `admin`, and `debug` to any local process that can access the socket. This seems broader than the HTTP/WS defaults, which use standard modules unless the operator opts into more. It also conflicts with the `testing` API documentation, which describes `testing_buildBlockV1` as highly sensitive and says the namespace must stay disabled by default. Relevant paths: - `crates/node/core/src/args/rpc_server.rs`: IPC is enabled by default with `ipcdisable: false` - `crates/rpc/rpc-builder/src/config.rs`: enabled IPC uses `RpcModuleSelection::default_ipc_modules()` - `crates/rpc/rpc-server-types/src/module.rs`: `default_ipc_modules()` returns `all_modules()` - `crates/rpc/rpc-api/src/testing.rs`: documents `testing` as sensitive and disabled-by-default ### Impact A local unprivileged process with access to the default IPC socket can call powerful RPCs without explicit operator opt-in. Examples include `testing_buildBlockV1`, `admin_clearTxpool`, peer mutation APIs, and heavy debug methods. ### Possible fix A safer default might be one of: - make IPC default to standard modules, matching HTTP/WS defaults - at minimum, exclude `testing` from default IPC modules - add an explicit `--ipc.api` flag for operators who want broader IPC access - consider warning when sensitive modules are enabled on IPC with permissive socket permissions I'm happy to fix this if maintainers agree on the desired default behavior.