Domain Business Events First

### Problem we must solve

Automation on Shopware (flow builder, app webhooks) reacts mostly to generic entity-write events — order.written, product.written, category.written — whose payload is only the entity name, operation, and primary key. Two consequences:

No domain meaning. A write event says something changed, not what happened. There is no signal for stock crossing zero, a product going live, a document generated, or a refund requested.
Every consumer must fetch. An id-only payload forces a follow-up API call to learn what changed, turning one write into many reads.

### WHY we need to solve it

Move from entity events to named, domain-specific business events that carry their data:

- Unlocks automation that entity writes can't express — stock/ERP sync, refund & dunning, document delivery, feed and multi-channel sync.
- Removes the follow-up fetch — the payload is enough to act on.
- Fires on every path (storefront, Admin API, Sync API, import), closing gaps like checkout.order.placed only firing on storefront checkout.
-

### Solution to the problem

One issue per owning team — 39 events:

| Team | Events | Covers |
|------|--------|--------|
| checkout | 14 | order, customer, address, refund request, promotion, tracking, wishlist |
| inventory | 11 | product lifecycle, stock & availability, publish, visibility, price |
| discovery | 12 | category, media, sales channel & domain |
| after-sales | 2 | document generated / deleted |

### WHO benefits

_No response_

### Accessibility

Backend-only work required

### WHERE will we do it

Shopware Core Platform

### Out of scope

_No response_

### Acceptance criteria

-

### Definition of Done

- [ ] Fulfills all acceptance criteria defined during discovery.
- [ ] Integration/E2E testing in staging is done.
- [ ] All integration/E2E/unit tests passing; all critical or high-priority bugs are resolved.
- [ ] Fulfills compliance, performance, security, and cloud-readiness needs.
- [ ] Observability—includes monitoring, alerting, and logging; incident response handbooks updated.
- [ ] Documentation—developer docs are written or updated, including information on how the feature or change is adopted and tested. If new functionality, end user documentation is written or updated.
- [ ] (conditional) All new API endpoints have a defined API schema.
- [ ] (conditional) If the change affects the Storefront, it has been tested in the latest three versions of Firefox, Chrome, Edge, IE11, and Safari, as well as the different viewports and devices (Desktop / Tablet / Mobile).
- [ ] (conditional) If the change affects the Administration, it has been tested in current versions of Firefox, Chrome, and Edge.
- [ ] (conditional) Functionality that includes new API routes are callable via the Store-API (/store-api/[version]/).
- [ ] (conditional) If a new Admin module is created, the access control layer is provided, and permissions can be managed via the Users & Permissions module.
- [ ] (conditional) If a new UI input field or interactive element is introduced, the ACL wrapper is added.
- [ ] (conditional) Performance testing done if the change has a high performance impact, such as affecting scalability, load balancing, or query optimization.

No files, tests, or entry points are named. Start with the 39-event table and the owning teams, then establish the missing acceptance criteria; done requires the listed integration, E2E, unit-test, documentation, observability, and compliance checks to pass.

Written by the indexing model from the issue text.