gcp traces submodule: drop the `replace gofr.dev` once a release contains pkg/gofr/traces/exporters

What

pkg/gofr/traces/exporters/gcp/go.mod carries

replace gofr.dev => ../../../../..

so the module builds in-tree against the unreleased pkg/gofr/traces/exporters package added by #4206. A replace in a dependency's go.mod is ignored by the consuming main module, so until a tagged gofr.dev release contains that package, go get gofr.dev/pkg/gofr/traces/exporters/gcp resolves gofr.dev v1.60.1 from the proxy — which does not have it — and the module is unusable outside this repository.

Why it needs an issue rather than the // TODO: it has today

This is a release-ordering constraint, not a cleanup nicety. The steps have to happen in order and someone has to remember them at tag time:

1. #4206 merges (pkg/gofr/traces/exporters lands on development).
2. A gofr.dev release is tagged that contains it.
3. pkg/gofr/traces/exporters/gcp/go.mod is bumped to that version and the replace is dropped.
4. The submodule is tagged pkg/gofr/traces/exporters/gcp/vX.Y.Z.

Until step 4, the module is in-repo only. A // TODO: in a go.mod is the weakest place to park that — raised in review of #4207.

Done when

pkg/gofr/traces/exporters/gcp/go.mod has no replace directive, pins a published gofr.dev version, and a go get of the module from a scratch directory outside this repo succeeds.