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.

package.json

@@ -111,7 +111,6 @@
     "eslint": "^9.8.0",
     "eslint-config-prettier": "^10.0.0",
     "eslint-plugin-playwright": "^1.6.2",
-    "grpc-tools": "^1.13.0",
     "husky": "^9.1.7",
     "jest": "^30.0.2",
     "jest-environment-node": "^30.0.2",
@@ -196,5 +195,8 @@
     "pino-http": "^11.0.0",
     "reflect-metadata": "^0.2.0",
     "rxjs": "~7.8.0"
+  },
+  "optionalDependencies": {
+    "grpc-tools": "^1.13.0"
   }
 }