fix(billing-service): import @fuzefront/shared via its declared ./kafka export

[github-actions]

Root cause: @fuzefront/shared's package.json declares an exports map with
exactly two entries, . and ./kafka. That map makes every undeclared
subpath unreachable under Node's package-exports resolution -
@fuzefront/shared/dist/kafka, which billing-service imported in six source
files (plus one test), is not a valid specifier for this package and should
raise ERR_PACKAGE_PATH_NOT_EXPORTED.

It only appeared to work because billing-service's production Dockerfile
copied shared/dist into the image without shared/package.json. With no
package.json present at that path, Node has no exports field to enforce,
so the deep path resolved by plain filesystem lookup instead - an accident
of packaging, not a valid resolution. applications-service hit the real
failure mode in #751: it copies both shared/dist and shared/package.json,
so the same deep import crash-looped it in prod (70 restarts) until fixed.
Adding the missing COPY line to billing-service, on its own, would have
reproduced that crash rather than fixed anything - the imports had to change
first.

Fix:

• All @fuzefront/shared/dist/kafka imports in services/billing-service now
  use the declared ./kafka subpath (src/index.ts, kafka/producer.ts,
  kafka/consumer.ts, kafka/ref-index.consumer.ts, kafka/org-deleted.consumer.ts,
  kafka/org-deleted.handler.ts, tests/kafka/org-deleted.handler.test.ts - two
  more source files and the one test than the issue's four call sites, found
  by grepping the whole service rather than trusting the listed set).
• jest.config.js moduleNameMapper key renamed to match the new specifier.
• tsconfig.json gains an explicit paths entry for @fuzefront/shared/kafka
  (baseUrl "." + relative path to shared/dist/kafka/index.d.ts), matching the
  existing convention in backend/tsconfig.json and backend/security/tsconfig.json
  for the same typed-import case.
• Dockerfile production stage now also COPYs shared/package.json alongside
  shared/dist, the same pairing applications-service's Dockerfile already
  uses (backend/applications/Dockerfile:86-87). Without the manifest, the
  correct subpath import would 404 in the image even though it type-checks
  and resolves locally - the exports map has to travel with the dist output
  for the supported entry point to actually be reachable at runtime.
• Removed billing-service from KNOWN_UNMIGRATED in
  backend/applications/tests/sharedSubpathExports.test.ts, so that guard now
  covers it as the issue asked.

Verified statically (no npm install / no image build - disk-constrained
worktree): re-implemented the guard test's file-scan logic against the
working tree and confirmed it finds 42 @fuzefront/shared import sites
repo-wide with zero offenders now that billing-service is migrated;
confirmed no shared/dist/kafka import specifier remains anywhere in the
repo (only paths/mapper targets, which correctly point at the physical
dist file); confirmed the edited tsconfig.json and jest.config.js both
parse; confirmed billing-service names no bare @fuzefront/shared import
that would additionally depend on the package's "main"/root export.

Co-Authored-By: Claude Opus 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_013tMciHkPE8To7V67CsgKKc

[izzywdev]

shipped code matches the frozen contract is failing here, and it is not this PR's defect.

GET  /v1/config/history         is declared in services/config-service/openapi.yaml
                                but no route implements it.
POST /v1/config/secrets/reveal  is declared in services/config-service/openapi.yaml
                                but no route implements it.
config-service: spec=9 code=7 -> 2 finding(s)

This PR touches only services/billing-service/** and shared/. Every other service in the same scan is conformant (billing-service, chat-service, notification-service, payment-service, selection-list-service, sms-service — all OK).

Why it surfaced here and not on the sibling PRs: the gate is path-filtered to services/**. This PR is the only one in the current batch that touches that tree, so it triggered a repo-wide conformance scan that reached config-service. Confirmed the same check reports not-run on #821, #822, #825 and #826.

It is a real defect, not a gate artifact. Verified directly: both paths are declared in services/config-service/openapi.yaml (lines 476 and 554) and neither is implemented anywhere under services/config-service/src/. config-service currently ships a frozen contract promising two endpoints that would 404 a generated client.

Fix is in flight separately — a dedicated PR is being prepared for config-service, per the gate's own instruction: "fix the CODE to match it, or change the contract deliberately — never regenerate the spec from the code." It is deliberately not folded in here, because implementing a reveal-once secrets endpoint is security-sensitive work that deserves its own review, and widening a dependency-import fix to carry it would bury both.

No re-run spent: a re-run cannot clear a missing route.

---

Generated by Claude Code

[claude]

shipped code matches the frozen contract is failing, and it is not this PR's.

::error title=config-service MISSING::GET /v1/config/history is declared in
  services/config-service/openapi.yaml but no route implements it.
::error title=config-service MISSING::POST /v1/config/secrets/reveal is declared in
  services/config-service/openapi.yaml but no route implements it.
config-service: spec=9 code=7 -> 2 finding(s)

Verified rather than assumed: python3 scripts/gate_openapi_conformance.py --repo . on a
pristine master checkout — none of this PR's diff present — reproduces both findings
identically. config-service ships an openapi.yaml declaring two endpoints it does not
implement, so any client generated from that contract 404s. Pre-existing on the base branch;
this PR does not touch services/config-service/.

The fix exists: #840 implements both endpoints (config-read.routes.ts gains
GET /v1/config/history behind a new history.repository.ts + migration 004, and
secrets.write.ts adds POST /v1/config/secrets/reveal). I have read it and it clears
exactly these two findings.

Not ported into this PR, deliberately. The protocol says to port an existing fix rather
than wait — but #840 is a 25-file, ~2,000-line feature implementation including a new SQL
migration. Carrying it here would not "no-op once the base catches up"; it would put two
copies of a migration and a repository layer into conflict and widen this PR into something
nobody reviewed it as. This is the narrow case where waiting on the base is correct: #840 is
at the front of the merge queue for precisely this reason, and this PR goes green on its
first resync afterwards with no change of its own.

No re-run spent — a re-run cannot fix a deterministic contract gap.

---

Generated by Claude Code