Synthesizes an incoming request and runs it through the full pipeline without requiring a listening server.

Removes a pending plugin by name before the application starts.

Plugins do not run until start(), so removing one here means its register() — and any eager side effect inside it, such as a database adapter's connect() — never happens at all. That is the one thing overriding a capability cannot do: an override replaces what consumers resolve, after the real plugin has already run.

Removing a plugin another plugin declares in dependencies is not refused here; start() reports it — naming the dependent plugin and the unsatisfied capability, though not the removed plugin's own name when the two differ (database-plugin provides database).

Removes every pending plugin carrying the name, not the first. Two may share one — the kernel refuses duplicates at start(), not at register() — and dropping one would leave the other running while the caller was told the name was gone.

Reports whether a plugin carrying this name is pending.

A pure read — it neither resolves nor constructs anything. It exists so a caller applying several exclusions can validate the whole set BEFORE removing any of them: unregister mutates immediately, so removing as you go leaves earlier exclusions applied when a later name turns out to be misspelled, handing a caller that catches the error a silently altered application.

Answers against the registered plugin list, which startup does NOT clear — so after start() it still reports true for a plugin that has already run. Its purpose is pre-start() validation, and unregister throws once any plugin has registered, so a later answer is not actionable either way.