docs(rename): update all URLs and references from python-eventing to messagekit

## Starting point: stale references after rename and PyPI publish

After renaming the GitHub repo, creating the new RTD project, and publishing
to PyPI as messagekit, documentation and config files still referenced the
old python-eventing name and python-eventing.readthedocs.io URLs.

## Changes

### pyproject.toml metadata
- Added author, license, keywords, classifiers, documentation URL
- Updated homepage/repository URLs to github.com/firstunicorn/messagekit

### README.md (13 replacements)
- All ReadTheDocs URLs from python-eventing.readthedocs.io to messagekit.readthedocs.io
- GitHub URLs already updated in prior commit

### docs/ (10 files)
- All ReadTheDocs URLs across dlq-handlers, consumer-transactions,
  transactional-outbox, cross-service-communication
- All prose references to python-eventing in integration-guide,
  troubleshooting, event-catalog, quickstart-docker-kafka, deployment README
- Updated install commands in integration-guide to pip install messagekit

### Other files
- docker-compose.yml: comment header
- scripts/tests/e2e/run_e2e_test.py: docstring
- scripts/tests/e2e/README.md: title

## Result

Zero python-eventing references remain in active code/docs.
Only frozen history (.specstory/, .cursor/plans/, memories/) retains old names.

Author: FirstUnicorn

README.md

@@ -1,6 +1,6 @@
 # Eventing
 
-[Documentation Status](https://python-eventing.readthedocs.io/en/latest/?badge=latest)
+[Documentation Status](https://messagekit.readthedocs.io/en/latest/?badge=latest)
 [Tests](https://github.com/firstunicorn/messagekit/actions)
 [Python](https://www.python.org/downloads/)
 [License](LICENSE)
@@ -21,7 +21,7 @@
 
 Package-first universal event infrastructure for microservices.
 
-📚 **[Full Documentation](https://python-eventing.readthedocs.io/en/latest/)** - Comprehensive guides and API reference
+📚 **[Full Documentation](https://messagekit.readthedocs.io/en/latest/)** - Comprehensive guides and API reference
 
 ## Installation
 
@@ -102,18 +102,18 @@ Support scale: `❌` none, `✅` basic, `✅✅` strong, `✅✅✅` first-class
 
 ## Documentation
 
-📖 **[Integration Guide](https://python-eventing.readthedocs.io/en/latest/integration-guide.html)** - Step-by-step integration instructions
+📖 **[Integration Guide](https://messagekit.readthedocs.io/en/latest/integration-guide.html)** - Step-by-step integration instructions
 
-🔍 **[API Reference](https://python-eventing.readthedocs.io/en/latest/autoapi/index.html)** - Complete API documentation
+🔍 **[API Reference](https://messagekit.readthedocs.io/en/latest/autoapi/index.html)** - Complete API documentation
 
-📋 **[Event Catalog](https://python-eventing.readthedocs.io/en/latest/event-catalog.html)** - Available event types and contracts
+📋 **[Event Catalog](https://messagekit.readthedocs.io/en/latest/event-catalog.html)** - Available event types and contracts
 
 ### Key topics
 
-- [Transactional Outbox Pattern](https://python-eventing.readthedocs.io/en/latest/transactional-outbox.html) - Guaranteed event delivery (PRIMARY)
-- [Cross-Service Communication](https://python-eventing.readthedocs.io/en/latest/cross-service-communication.html) - Database isolation, Kafka/RabbitMQ architecture, production deployment
-- [Idempotent Consumers](https://python-eventing.readthedocs.io/en/latest/consumer-transactions.html) - Duplicate message handling
-- [Health Checks](https://python-eventing.readthedocs.io/en/latest/autoapi/eventing/infrastructure/health/index.html) - Monitoring outbox and broker status
+- [Transactional Outbox Pattern](https://messagekit.readthedocs.io/en/latest/transactional-outbox.html) - Guaranteed event delivery (PRIMARY)
+- [Cross-Service Communication](https://messagekit.readthedocs.io/en/latest/cross-service-communication.html) - Database isolation, Kafka/RabbitMQ architecture, production deployment
+- [Idempotent Consumers](https://messagekit.readthedocs.io/en/latest/consumer-transactions.html) - Duplicate message handling
+- [Health Checks](https://messagekit.readthedocs.io/en/latest/autoapi/eventing/infrastructure/health/index.html) - Monitoring outbox and broker status
 
 **Architecture note**: This package handles the **write side** of the outbox pattern (persisting events transactionally with business data). **Publishing** is delegated to Kafka Connect with Debezium CDC, which captures outbox table changes and publishes to Kafka. The **bridge component** (part of standard architecture) forwards events from Kafka to RabbitMQ for services preferring AMQP. Dead letter handling leverages native broker mechanisms (RabbitMQ DLX, Kafka Connect DLQ SMT) with a minimal bookkeeping consumer to maintain database failed-event flags.
 
@@ -196,7 +196,7 @@ flowchart LR
 - **Publish Phase**: ✅ At-least-once (CDC retries on failure)
 - **Consume Phase**: ✅ Exactly-once (idempotency via processed message store in consumer's database)
 
-📖 **[Cross-Service Communication Guide](https://python-eventing.readthedocs.io/en/latest/cross-service-communication.html)** - Detailed explanation with production deployment patterns
+📖 **[Cross-Service Communication Guide](https://messagekit.readthedocs.io/en/latest/cross-service-communication.html)** - Detailed explanation with production deployment patterns
 
 ### Database isolation and event flow
 
@@ -465,7 +465,7 @@ async def startup():
     app.state.event_bus = event_bus
 ```
 
-**CDC Publishing:** Kafka Connect with Debezium CDC automatically detects outbox table changes and publishes to Kafka. See [`debezium-cdc-architecture.md`](https://python-eventing.readthedocs.io/en/latest/debezium-cdc-architecture.html) for configuration.
+**CDC Publishing:** Kafka Connect with Debezium CDC automatically detects outbox table changes and publishes to Kafka. See [`debezium-cdc-architecture.md`](https://messagekit.readthedocs.io/en/latest/debezium-cdc-architecture.html) for configuration.
 
 ## Quick Start: Transactional Outbox
 

docker-compose.yml

@@ -1,6 +1,6 @@
 version: '3.8'
 
-# Docker Compose for python-eventing + Kafka local development
+# Docker Compose for messagekit + Kafka local development
 
 networks:
   eventing-network:

docs/deployment/README.md

@@ -1,14 +1,14 @@
 # Deployment Documentation
 
-Guide for running python-eventing with Kafka infrastructure.
+Guide for running messagekit with Kafka infrastructure.
 
 ## Quick start
 
 [quickstart-docker-kafka.md](./quickstart-docker-kafka.md) - Complete setup with Docker Compose
 
 ## Two Publishing Patterns
 
-python-eventing supports two approaches:
+messagekit supports two approaches:
 
 1. **Direct Publishing** - Publish events directly to Kafka (simpler, Kafka only)
 2. **Transactional Outbox** - Write to DB, CDC publishes to Kafka (robust, requires PostgreSQL + Kafka Connect)

docs/deployment/quickstart-docker-kafka.md

@@ -1,6 +1,6 @@
-# Quick Start: python-eventing with Docker Kafka
+# Quick Start: messagekit with Docker Kafka
 
-Get python-eventing running with Docker Kafka.
+Get messagekit running with Docker Kafka.
 
 ## Prerequisites
 
@@ -10,7 +10,7 @@ Get python-eventing running with Docker Kafka.
 
 ## Two Publishing Patterns
 
-python-eventing supports two approaches:
+messagekit supports two approaches:
 
 ### 1. Direct Publishing (simpler)
 Publish events directly to Kafka - no database, no CDC needed.
@@ -99,10 +99,10 @@ Wait for health checks (~30 seconds):
 docker-compose ps
 ```
 
-### 3. Install python-eventing
+### 3. Install messagekit
 
 ```bash
-pip install python-eventing faststream[kafka]
+pip install messagekit faststream[kafka]
 
 # For transactional outbox, also install:
 pip install sqlalchemy asyncpg
@@ -133,7 +133,7 @@ For transactional outbox pattern, configure Debezium CDC connector. This tells K
 | `database.password` | `postgres` | From docker-compose.yml `POSTGRES_PASSWORD` |
 | `database.dbname` | `eventing` | From docker-compose.yml `POSTGRES_DB` |
 | `database.server.name` | `myapp` | Arbitrary logical name (choose any) |
-| `table.include.list` | `public.outbox_events` | Table name from python-eventing ORM model |
+| `table.include.list` | `public.outbox_events` | Table name from messagekit ORM model |
 
 **Create the connector:**
 
@@ -219,4 +219,4 @@ curl http://localhost:8083/connectors/outbox-connector/status
 
 - [docker-compose.yml](../../docker-compose.yml) - Infrastructure definition
 - [.env.example](../../.env.example) - Configuration template
-- python-eventing docs: https://python-eventing.readthedocs.io/
+- messagekit docs: https://messagekit.readthedocs.io/

docs/source/consumer-transactions.md

@@ -1,8 +1,8 @@
 # Consumer transaction management guide
 
-**API Reference:** [IdempotentConsumerBase](https://python-eventing.readthedocs.io/en/latest/autoapi/messagekit/infrastructure/messaging/kafka_consumer_base/index.html)
+**API Reference:** [IdempotentConsumerBase](https://messagekit.readthedocs.io/en/latest/autoapi/messagekit/infrastructure/messaging/kafka_consumer_base/index.html)
 
-**Integration Guide:** [Consume idempotently](https://python-eventing.readthedocs.io/en/latest/integration-guide.html#consume-idempotently)
+**Integration Guide:** [Consume idempotently](https://messagekit.readthedocs.io/en/latest/integration-guide.html#consume-idempotently)
 
 ## Overview
 

docs/source/cross-service-communication.md

@@ -2,7 +2,7 @@
 
 ## Overview
 
-`python-eventing` enables reliable event-driven communication between microservices following the **database-per-service** pattern. Each service maintains its own PostgreSQL database and communicates via shared Kafka infrastructure.
+`messagekit` enables reliable event-driven communication between microservices following the **database-per-service** pattern. Each service maintains its own PostgreSQL database and communicates via shared Kafka infrastructure.
 
 ## Architecture principle: Database isolation
 
@@ -369,7 +369,7 @@ All services on the **same Docker network** enable automatic service discovery v
 
 ### Configuration via environment variables
 
-Each service configures `python-eventing` via environment variables (read by Pydantic Settings):
+Each service configures `messagekit` via environment variables (read by Pydantic Settings):
 
 **Service A (Producer):**
 ```ini
@@ -548,7 +548,7 @@ async with session.begin():
 
 ## See also
 
-- {doc}`integration-guide` - How to integrate `python-eventing` in your service
+- {doc}`integration-guide` - How to integrate `messagekit` in your service
 - {doc}`transactional-outbox` - Outbox pattern details
 - {doc}`consumer-transactions` - Idempotent consumer pattern
 - {doc}`dlq-handlers` - Dead letter queue handling

docs/source/dlq-handlers.md

@@ -1,6 +1,6 @@
 # Dead letter queue (DLQ) handler guide
 
-**API Reference:** [Universal DLQ Handler](https://python-eventing.readthedocs.io/en/latest/autoapi/messagekit/infrastructure/messaging/index.html) | [Kafka DLQ Handler](https://python-eventing.readthedocs.io/en/latest/autoapi/messagekit/infrastructure/messaging/kafka/index.html)
+**API Reference:** [Universal DLQ Handler](https://messagekit.readthedocs.io/en/latest/autoapi/messagekit/infrastructure/messaging/index.html) | [Kafka DLQ Handler](https://messagekit.readthedocs.io/en/latest/autoapi/messagekit/infrastructure/messaging/kafka/index.html)
 
 ## Overview
 

docs/source/event-catalog.md

@@ -52,7 +52,7 @@ events and services against TOML registries:
 
 **Your organization's catalog repository structure:**
 
-This is the structure for your own centralized event catalog Git repository (not part of the `python-eventing` library):
+This is the structure for your own centralized event catalog Git repository (not part of the `messagekit` library):
 
 ```
 your-event-catalog/
@@ -80,7 +80,7 @@ events_published = ["orders.order.created"]
 
 ## Published domain event examples
 
-> **Note:** The events below are purely illustrative examples. The `python-eventing` library does *not* contain any hardcoded business payloads or domains (like gamification).
+> **Note:** The events below are purely illustrative examples. The `messagekit` library does *not* contain any hardcoded business payloads or domains (like gamification).
 
 The eventing service does not define producer-specific business payloads.
 Instead, it provides the reusable base contract that other services extend. The

docs/source/integration-guide.md

@@ -1,6 +1,6 @@
 # Integration guide
 
-Use the `python-eventing` package when a domain service needs both local
+Use the `messagekit` package when a domain service needs both local
 in-process dispatch and reliable cross-service publication.
 
 **For detailed cross-service architecture:** See {doc}`cross-service-communication` for database isolation patterns, Kafka/RabbitMQ architecture, and production deployment examples.
@@ -12,19 +12,18 @@ Add to your project's `pyproject.toml`:
 ```toml
 [tool.poetry.dependencies]
 python = "^3.12"
-python-eventing = "^0.1.0"
+messagekit = "^0.1.0"
 ```
 
 Or install directly:
 
 ```bash
-pip install python-eventing
+pip install messagekit
 # or
-poetry add python-eventing
+poetry add messagekit
 ```
 
-The published distribution name is `python-eventing`, while Python imports use
-`from messagekit ...` (not `eventing`).
+The distribution and import name is `messagekit`:
 
 ## Add a new event schema
 

docs/source/transactional-outbox.md

@@ -1,6 +1,6 @@
 # Transactional outbox pattern - usage guide
 
-**Full documentation:** [Integration Guide - Publish through the outbox](https://python-eventing.readthedocs.io/en/latest/integration-guide.html#publish-through-the-outbox)
+**Full documentation:** [Integration Guide - Publish through the outbox](https://messagekit.readthedocs.io/en/latest/integration-guide.html#publish-through-the-outbox)
 
 ## Overview