fix(ci): move grpc-tools to optionalDependencies (revert NODE_OPTIONS attempt)

The NODE_OPTIONS=--use-system-ca workaround merged in #199 did not
clear the failure — the same TLS-chain rejection still trips the
runner. Either the runner's OS CA store also lacks the missing
intermediate, or `--use-system-ca` does not propagate down to the
node-fetch@2 used by node-pre-gyp. Without runner shell access the
exact reason is not worth investigating.

Different angle: grpc-tools is never invoked in CI. The protoc
binary it downloads is only used by `pnpm run grpc:codegen`, which
runs on a developer's machine when a proto file changes. The
generated TypeScript stubs in apps/portal-bff/src/grpc/gen/ are
committed (per ADR-0024 §"Sub-decision 3 — vendored protos"), so
CI only needs to type-check them — protoc is dead weight there.

Move grpc-tools from devDependencies to optionalDependencies. Per
pnpm semantics, an optional dependency whose install (including
postinstall) fails is logged as a warning and the overall install
continues. On the runner: postinstall still fails on TLS, pnpm
emits a warning, ci:check proceeds. On a developer machine: TLS
validates, postinstall runs, protoc binary lands, `pnpm grpc:codegen`
works exactly as before. No dev-side friction; no workflow env
vars to maintain.

Reverts the workflow `env:` blocks added in #199 — they did not
help and adding noise to the workflow YAML for a non-working
workaround is worse than removing it.

.gitea/workflows/docs-site.yml

@@ -28,13 +28,6 @@ on:
       - 'pnpm-lock.yaml'
       - '.gitea/workflows/docs-site.yml'
 
-# See `.gitea/workflows/ci.yml` for the rationale — Node 24's
-# bundled CA set rejects some chains the runner's OS trust store
-# validates, and `--use-system-ca` (Node ≥ 22) tells Node to
-# consult the OS CA bundle alongside its own.
-env:
-  NODE_OPTIONS: --use-system-ca
-
 jobs:
   build:
     runs-on: [self-hosted, on-prem]