Tighten DDD layering: pure Domain, injected renderers, trimmed EntryOperations

[GaryJones]

Summary

Architectural follow-up against 2.x after reviewing the DDD refactor. Three concerns surfaced from the review and are addressed here in three commits, each independently green.

LiveblogPost lived under Domain/Entity/ but called update_post_meta, delete_post_meta, post_type_supports, current_user_can, do_action and apply_filters directly. That made it a WordPress-aware aggregate, not a persistence-agnostic domain entity. Moving it to Application/Aggregate/ matches what the class actually is, and leaves the Domain layer holding only Entry, the value objects and EntryRepositoryInterface — all of which are genuinely free of WordPress dependencies. No behaviour change; only the namespace and 28 imports move with it.

Three Application-layer classes (EntryPresenter, KeyEventShortcodeHandler, LazyloadConfiguration) reached back into Container::instance() at runtime to fetch a renderer. That inverts the dependency direction and hides the dependency from the constructor. Each one now declares the renderer it needs as a constructor parameter, with the wiring done once in Container or PluginBootstrapper. A new Application\Renderer\TemplateRendererInterface mirrors the existing ContentRendererInterface, so Application code never imports the concrete TemplateRenderer from Infrastructure. EntryPresenter loses an unreachable render() method in passing.

The same commit also untangles a circular dependency: EntryService accepted an optional KeyEventService constructor argument with a lazy fallback that constructed a fresh KeyEventService and EntryQueryService on demand. The lazy create silently bypassed any test double a caller had wired up. The only path that needed it — delete_key — is called exclusively from EntryOperations::execute_delete_key, which already has both services injected. Moving the two-step orchestration up to that caller lets EntryService collapse to a single repository-only constructor, and the cycle is gone.

Finally, EntryOperations had seven public pass-through methods (insert, update, delete, is_key_event, remove_key_action plus entry_service() and key_event_service() accessors) that call-site mapping showed have no external callers. They were leftover scaffolding from an earlier refactor, documented as a facade for legacy container access that no longer exists. Removing them, together with rewriting the class docblock to describe what the class actually does — dispatch CRUD action strings, apply the liveblog_*_entry filters and actions around each mutation, and prepare the JSON payload for REST and admin-ajax callers — leaves a clear public surface of do_crud, format_preview and is_valid_action.

What this PR does not do: replace the hand-rolled service-locator container, collapse the single-implementation ContentRendererInterface and EmbedHandlerInterface, or extract a LiveblogPostRepository. Those were considered and judged either out of scope or actively unhelpful at the current size of the codebase.

Test plan

• composer install && vendor/bin/phpunit --testsuite unit — 190 tests, all green at HEAD and at each intermediate commit.
• vendor/bin/phpcs src/php --standard=.phpcs.xml.dist — clean.
• Smoke test in wp-env: create a liveblog, post an entry, edit an entry, mark an entry as key event then unmark it, archive the post. The CRUD path exercises both REST and admin-ajax routes that depend on the new constructor wiring.