Refuse incomplete root-testing activation before a <Test> runs

[taras]

Story

As a programmatic testing host, I want incomplete root-testing composition to
fail before a test body runs, so a missing collector, final-result flush, or
completion policy cannot turn failed tests into a successful document execution.

Current defect

The following composition is not a supported root testing session:

yield* installTestingComponents();
yield* Test.around({ testing: () => true });

It does activate test behavior. A <Test> expands its body, assertions run and
the testing package classifies the result. The result is then staged so an
invocation teardown failure can still change it before publication.

What this composition omits is the rest of the root boundary that
useTesting() installs:

• the result collector;
• the final staged-result flush; and
• the completion policy that turns a failed or empty suite into
  Err(TestFailureError).

With one test, the staged result is never flushed. A passing test therefore
renders a pass report and completes Ok with no recorded result. More
importantly, a failing test renders its failure report but the failure remains
contained by <Test>, the document completes Ok, and a surrounding collector
receives no result. With several tests, staging the next test may flush earlier
results, but the final result and the root completion decision remain missing.

This is not inactive-test behavior. When testing mode is inactive, the settled
contract remains that <Test> and its entire body are skipped: no rendering,
binding, side effect, or result.

Settled contract

There are two complete testing activations:

• useTesting() activates one root document execution, owns its collection,
  flush and completion policy, and supports exactly one execute() call in its
  scope; and
• <Testing> activates one lexical subtree, owns its boundary collection,
  flush and completion policy, and reports its own outcome.

installTestingComponents() registers testing behavior and components. It is
not a root activation API. A bare public Test middleware override that makes
testing true does not establish either complete activation.

If canonical <Test> is reached with testing === true but without the exact
complete root or lexical activation established by the testing package, the
execution fails before the test body expands. This is a testing-configuration
failure, not a failed or skipped TestResult: it is not contained as the test's
outcome, it records no test result, and it cannot be converted into a successful
document result by the missing completion policy.

Public TestApi middleware remains policy. It may observe, narrow, refuse, and
compose recording behavior, but it cannot manufacture the testing package's
complete-activation authority or rescue an execution by installing only the
boolean mode.

No skipped status is added. Dormant tests remain invisible, and skip, focus,
and retry remain unsupported.

Multiple programmatic executions

One useTesting() session continues to support one execute() call. A harness
that runs several documents creates one child Effection scope and one
useTesting() session per document execution:

for (const document of documents) {
 yield* scoped(function* () {
 const tests = yield* useTesting();
 const execution = yield* executeInstalled(document.options, document.installations);
 const outcome = yield* execution;
 const results = yield* tests.results;
 // inspect this execution's outcome and results
 });
}

Fixture state, provider middleware and durable stores that must survive across
those executions belong to the enclosing scope and are inherited by each child.
A document testing another root from Markdown continues to use <Execution>
and the host profile its trusted host supplies.

Acceptance

• useTesting() still records every result in discovery order, flushes the
  final result, fails an otherwise successful execution when a test failed, and
  fails a zero-test execution.
• An explicit <Testing> boundary still records every result, flushes its final
  result, fails on a failed or empty boundary, and works during an otherwise
  ordinary run.
• installTestingComponents() without activation still skips <Test> and its
  whole body, renders nothing for it, performs none of its side effects, and
  records no result.
• installTestingComponents() plus bare
  Test.around({ testing: () => true }) fails before the first <Test> body
  expands. A sentinel in the body does not run, no assertion diagnostic renders,
  no TestResult is recorded or journaled, and the document completion is
  Err.
• The same refusal holds for passing and failing bodies and under
  executeInstalled(); a workflow installation does not turn partial testing
  composition into a session.
• Public TestApi middleware cannot fabricate the package-owned indication of
  complete activation, suppress the configuration failure, or make the
  incomplete execution complete successfully.
• A harness can run two documents under shared outer fixture/provider state by
  giving each execution its own child scope and useTesting() session; results
  and completion policy do not cross between them.
• Full replay restores supported testing results and outcomes exactly as today.
  The incomplete-activation refusal produces no testing result to restore.
• Loaded copies preserve the existing testing behavior and recording
  composition without turning a stable public context or API name into complete
  activation authority.

Use a focused regression that proves the body sentinel remains untouched and
that the manual failing case changes from Ok plus no results to a pre-body
Err. Do not rely only on the absence of results: that was the vacuous signal
that exposed this defect.

Documentation

• specs/testing-spec.md distinguishes component registration, boolean testing
  mode, and the complete root or lexical boundary that owns collection, final
  flushing and completion.
• architecture.md records that complete testing activation and settlement are
  package-owned; public TestApi middleware is policy and cannot manufacture
  them.
• The public @executablemd/testing module documentation shows one
  useTesting() session per child execution scope for multi-document
  programmatic harnesses.

Sequencing

This is testing-API hardening and does not block #516, #522, or #181. PR #516
must use the supported per-execution useTesting() composition rather than the
incomplete shortcut. #522 may proceed against #516's corrected feedback commit
or merged result.

Out of scope

• A multi-execution useTesting() session or cumulative result partitioning.
• A skipped TestResult, skip/focus/retry language, or visible dormant tests.
• A new testing DSL or mocking mechanism.
• The unbuilt host="workflow" nested-execution profile.
• Changes to canonical <Test> ownership or checked-command-failure
  containment.