refactor: read ghreplica mirror data directly

[dutifulbob]

Summary

PRtags no longer calls the ghreplica HTTP API for internal mirror metadata reads.
It now reads mirrored GitHub repositories, issues, and pull requests through the shared ghreplica/mirror Go package.
This is the code path needed for the shared Postgres database cutover, where PRtags keeps its own schema but reads mirror data directly from the same database.

What Changed

The internal ghreplica adapter is now a direct database reader instead of an HTTP client.
The service still keeps the product boundary: ghreplica owns mirror data, and PRtags owns groups, annotations, projections, jobs, and comment sync.

• Replaced the internal prtags -> ghreplica HTTP client with a wrapper around mirror.Reader.
• Added configurable PRTAGS_SCHEMA and GHREPLICA_SCHEMA settings.
• Set PRtags database connections to use the configured PRtags schema through Postgres search_path.
• Updated deployment docs and compose env wiring for the shared database topology.
• Removed obsolete HTTP-client tests and replaced them with direct mirror reader tests.

Testing

The local code path is covered before production cutover.
The production data copy has already passed a transaction-wrapped dry run, but the real copy will be done during deployment so writes are not missed.

• go test ./...
• tmpdir=$(mktemp -d); env -u GITHUB_TOKEN -u GH_TOKEN -u PRTAGS_GITHUB_TOKEN PRTAGS_CONFIG_DIR="$tmpdir" ./scripts/check-go-coverage.sh
• golangci-lint run --timeout=5m
• npx --yes @simpledoc/simpledoc@0.1.6 check
• git diff --check

Risks

The main rollout risk is database topology, not the code adapter.
PRtags must be pointed at the shared database with PRTAGS_SCHEMA=prtags after the old PRtags data is restored into that schema.

• The public ghreplica HTTP API remains available for external callers.
• PRtags still uses GitHub API calls for GitHub-owned writes such as comment sync.
• Rollback is to point PRtags back at the old database and previous image if the shared DB cutover fails.