Decide the coverage threshold gate once the post-merge figure is published (follow-up to #3940)

Context

#3940 folds the datasource and metrics-exporter submodules into the reported coverage figure. Before it, parse_coverage and upload_coverage merged only the Example and PKG profiles, so the published percentage excluded every module under pkg/gofr/datasource/* and pkg/gofr/metrics/exporters/* while presenting as a whole-repo number.

A threshold gate used to live in parse_coverage as a commented-out 92% check. #3940 deliberately did not restore it, and review agreed the reasoning was right but asked that the decision live in the queue rather than in a YAML comment. This is that issue.

The decision

Once a run on development has published the post-merge figure, decide:

1. Restore the gate at a floor picked from that number, or
2. Delete the commented-out block and keep parse_coverage as reporting only.

A floor cannot be chosen before the number exists — #3940 moves the reported figure for the first time in a long while, and picking 92% (or anything else) beforehand is a guess.

What the number now includes

• Example, PKG and submodule profiles, merged identically in parse_coverage and upload_coverage so the PR figure and the qlty figure cannot drift.
• Generated mocks are stripped (grep -v '/mock_') in both merges, matching the filter the PKG job already applies before uploading its profile. Without it the two halves of one number were computed under different rules — 66 mock_*.go files live under the submodules.

Where the gate goes

.github/workflows/go.yml, in parse_coverage, after the Parse code-coverage value step. CODE_COVERAGE is already exported to $GITHUB_ENV and the figure is written to $GITHUB_STEP_SUMMARY.