fix(external-kafka): Refresh patches so they apply to master again

[oioki]

The external Kafka patches in optional-modifications/ no longer applied cleanly to master, so following the README left the bundled kafka service in place:

• docker-compose.yml.patch: the hunk that removes the kafka service still had the old service definition as context (image 7.6.6, 24h retention, 4096 nofile), so it was rejected. Regenerated from master; apart from that block's context, the changes are the same as before.
• .env.patch: expected .env to end at SETUP_JS_SDK_ASSETS. Regenerated so the same block is appended to the end of the current .env.
• launchpad-taskworker was added after the patch and still depended on the bundled kafka service, which made the patched compose project invalid (depends on undefined service "kafka"). It now uses KAFKA_BOOTSTRAP_SERVERS and no longer depends on kafka. Launchpad only reads the bootstrap servers, so it can't use SASL/SSL settings yet.

All four patches now apply with patch -p0 in the README order, and docker compose config accepts the result.

The kafka hunk carries the whole service definition as context, so it will go stale again whenever that block changes (for example a Dependabot bump of cp-kafka). A CI step that runs patch --dry-run would catch that.

[github-actions]

Coverage Results 📊

✅ 22 passed | Total: 22 | Pass Rate: 100% | Execution Time: 11m 4s

All tests are passing successfully.

✅ Patch coverage is 100.00% (no changed executable lines found; target 50%).
Project statement coverage is 95.52% (unchanged from base (3f77a67) to head (414c892)).

Coverage diff

@@            Coverage Diff             @@
##        master     #4553       +/-##
==========================================
  Coverage    95.52%    95.52%        —%
==========================================
  Files            5         5         —
  Tracked lines       335       335         —
  Branches         0         0         —
==========================================
  Hits           320       320         —
  Misses          15        15         —
  Partials         0         0         —

---

Generated by Coverage Action

[sentry]

Bug: The patch unconditionally adds a bind mount for ./certificates/kafka, which doesn't exist by default. This will cause docker compose up to fail on recent Docker versions.
_{Severity: CRITICAL}

Suggested Fix

The bind mount for ./certificates/kafka should be made conditional so it is only applied when Kafka SSL is enabled. Alternatively, the certificates/kafka directory could be created in the repository with a .gitkeep file to ensure it always exists, preventing the startup error.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: optional-modifications/patches/external-kafka/docker-compose.yml.patch#L102

Potential issue: The patch unconditionally adds a bind mount for the
`./certificates/kafka` directory to the `relay` and `vroom` services. This directory
does not exist by default and is only intended for use when Kafka SSL is enabled. On
modern versions of Docker (v23+), which no longer automatically create missing source
paths for bind mounts, this will cause `docker compose up` to fail with a 'bind source
path does not exist' error. This failure prevents the `relay` and `vroom` services from
starting, which breaks critical functionality like event ingestion and profile
processing for any user not using SSL, which is the default configuration.

Also affects:

• optional-modifications/patches/external-kafka/docker-compose.yml.patch:163~163

_{Did we get this right? 👍 / 👎 to inform future reviews.}