Upgrade go-common Library for Kafka Improvements

Upgrade `github.com/example/go-common` to the target version `v1.193.0` (adjust
before running) across every Go service.

For each repository:
1. Confirm the repo depends on `github.com/example/go-common` in `go.mod`. Skip
   repos that do not.
2. Bump the `require` line to `v1.193.0`. If the repo uses a `replace` directive
   pinning to a fork or local path, skip the repo and flag for review.
3. Run `go mod tidy` to refresh `go.sum`.
4. Apply the breaking-change call-site map (release notes for v1.181.0..v1.193.0):
   - `kafka.NewProducer(cfg)` → `kafka.NewProducer(ctx, cfg)` (new context argument)
   - `metrics.NewCounter("name")` → `metrics.NewCounter(metrics.CounterOpts{Name: "name"})`
   - `tracing.StartSpan(name)` → `tracing.StartSpan(ctx, name)`
   - Any other renames provided in the prompt
5. Run `go build ./...` then `go test ./...`. If either fails:
   - Prepend `[BUILD-FAILING]` (or `[TESTS-FAILING]`) to the PR title so the
     repo is filterable in the GitHub PR list.
   - Include the full failure output in the PR body under a
     `## Build / Test failures` section.
   - Add the repo to the rollout triage list.
6. Update CI Go version in `.github/workflows/*.yml` only if the target release
   requires it.

The Problem

Internal shared libraries are some of the hardest things to roll out at scale. The `go-common` library ships the latest Kafka client wrappers, retry policies, and tracing setup, but every service pins its own version, and the lag between releasing and adoption can be six months or more.

When a new release lands with critical fixes (rebalancing bugs, metric label changes, dependency CVEs), the platform team has to chase every service team to upgrade. The actual change is one line in `go.mod`, but the verification (build, test, deploy) is per-service.

What Tidra Does

1. Identifies every Go service depending on go-common via go.mod
2. Bumps the version to the target release and runs go mod tidy
3. Detects breaking-change callsites flagged in the release notes and updates them (e.g., renamed metric constructors, new context params)
4. Runs go build ./... and go test ./... per repo and surfaces failing repos in a triage list
5. Opens one PR per repo with a link to the release notes and a checklist for service owners

Before & After

Customization Tips

• Target version: Provide the target version explicitly. Tidra does not pick "latest" implicitly, you stay in control.
• Breaking-change map: For breaking changes, provide a "from → to" map (old API → new API). Tidra applies it during the upgrade.
• Test gating: Configure whether PRs open even if tests fail (with a [TESTS-FAILING] title prefix and failure output in the PR body) or only when green.