Gate the gRPC server (cardano-rpc) behind a manual cabal flag

## Problem

The node unconditionally links the UTxO-RPC/gRPC stack (`grapesy`, `tls`, `http2`, protobuf — 20+ third-party packages). Ecosystem migrations in that stack now block unrelated work: the `crypton ^>= 1.1` (`memory` → `ram`) bump in `cardano-base` can't co-exist with the current gRPC constraints, stalling cross-repo integration until each upstream package is patched ([Slack thread](https://input-output-rnd.slack.com/archives/CCZSDE005/p1786120823337109)). This was predicted in the [ADR-018 review](https://github.com/input-output-hk/cardano-node-wiki/pull/90#discussion_r2947020442).

Note the crypton migration also conflicts with old pins in IOG-owned packages (`cardano-addresses`, `cardano-crypto`, `cardano-prelude-test`, …), but those are within our control and fixable same-day. The gRPC stack is the only part of the closure where we are blocked waiting on third-party maintainers — that is the part this issue addresses.

## Proposal

Add a **manual**, **default-on** cabal flag (`grpc`) to `cardano-node`:

- Flag-on (default): identical to today — releases, CI, and plain builds unaffected.
- Flag-off (`-f -grpc`): `cardano-rpc` and the gRPC stack are excluded from the build plan entirely.
- Config requesting the RPC server in a flag-off build fails with a hard error.
- The flag-off state is a best-effort development escape hatch, not a supported build configuration: it is not covered by CI and not shipped. If it doesn't compile, fix the guard or ping the cardano-rpc maintainers.

## The workflow this enables

**If you are doing integration work and hit resolver conflicts from the gRPC stack, you are not expected to fix them.** Switch the server off and carry on:

```
-- cabal.project.local
package cardano-node
flags: -grpc
```

Then ping the cardano-rpc maintainers (node-api team), who own getting the gRPC closure to resolve again — via upstream patches or CHaP vendoring — before the next release. Dependency fallout from that stack is their responsibility, not a problem for whoever happens to bump a crypto or ledger dependency.

## Notes

- Release binaries keep the full closure — this changes who pays and when, not whether.