Framework should auto-register gRPC histograms like HTTP and datasource metrics

## Problem

`container.go` auto-registers histograms with tuned bucket boundaries for:
- `app_http_stats` (lines ~244)
- `app_redis_stats`, `app_sql_stats`, and other datasource metrics (lines ~252-258, via `getDefaultDatasourceBuckets()`)

But `app_gRPC-Server_stats` and `app_gRPC-Stream_stats` are **not** auto-registered anywhere in the framework. The interceptors (`ObservabilityInterceptor` and `StreamObservabilityInterceptor` in `grpc/log.go`) call `metrics.RecordHistogram()` on these names, so they silently work — but they end up using OTel's default buckets instead of framework-tuned ones.

Users who don't manually register these histograms get no warning and no indication that their bucket boundaries are wrong. The only reference is the example code in `examples/grpc/`, which itself has a max bucket of 10ms (separate issue).

## Expected behavior

When the gRPC server is enabled, the framework should register `app_gRPC-Server_stats` and `app_gRPC-Stream_stats` with sensible default bucket boundaries — same as it does for HTTP and datasource metrics. Users should still be able to override with custom buckets if they want.

## Where to look

- `container/container.go` — where HTTP and datasource histograms are registered
- `grpc/log.go` — where `recordGRPCMetrics()` uses these metric names
- `examples/grpc/grpc-unary-server/server/health_gofr.go` — current workaround in example code

Start in container/container.go by comparing HTTP and datasource histogram registration, then inspect recordGRPCMetrics() in grpc/log.go and the workaround in examples/grpc/grpc-unary-server/server/health_gofr.go. Confirm how gRPC enablement and custom buckets are handled; done means both named gRPC histograms receive framework defaults when enabled while user overrides remain effective.

Written by the indexing model from the issue text.