Documented dispatch-level pool scoping (with_execution) does not exist

[GeneralPawz]

The threading page documents a dispatch-level integration that does
not exist in the tree. Found while auditing whether the facade
parallel feature reaches the crates that actually thread.

What the docs claim

docs/architecture/threading.md states, as shipped design:

MeshBooleanRegistry::with_execution (in axiolid-dispatch, gated
behind this crate own parallel feature) wraps every dispatched
provider call in a CpuExecution local rayon pool via
ThreadPool::install [...] This is orthogonal to the decision above
and remains supported.

What is actually there

At bf82e2c:

• with_execution does not exist anywhere in crates/, tools/, or
  tests/ -- zero matches.
• axiolid-dispatch has no parallel feature. Its full feature list is
  default, mesh-boolean, mesh-section, pointcloud-reconstruction.
• axiolid-dispatch does not depend on axiolid-backend-cpu at all, so
  it could not construct a CpuExecution to install into.

What DOES work

The capability exists one level down and is genuinely usable:
CpuExecution::install is public under the parallel feature and
scopes a closure into the context local pool. An application can build
a CpuExecution and wrap its own provider calls today.

What is missing is the dispatch-level seam that would apply that pool
to every dispatched provider call without the caller threading it
through by hand.

Why this matters beyond a stale sentence

The page uses this seam to justify keeping the layering rule: providers
must not depend on axiolid-backend-cpu, and scoping lives in dispatch
instead. That argument is sound, but the implementation it points at is
not present, so today there is no pool-scoping layer between an
application and a provider internal rayon usage.

Concretely: boolmesh uses rayon directly when its own parallel
feature is on. Nothing bounds that to a caller pool, so it would run on
the ambient global pool -- which is exactly what the documented design
says it prevents.

Options

1. Implement it. Add a parallel feature to axiolid-dispatch, an
   optional axiolid-backend-cpu dependency, and
   MeshBooleanRegistry::with_execution wrapping dispatched calls in
   CpuExecution::install. Makes the docs true and gives the facade
   parallel feature a real job.
2. Correct the docs. Describe CpuExecution::install as the
   supported mechanism and state that dispatch-level scoping is not
   implemented.

Option 1 is the better end state; option 2 should happen immediately
either way, since the page currently describes shipped behaviour that
does not exist.

Found at bf82e2c.

[GeneralPawz]

Implemented in 69c6903, rather than documented away.

Shape

All three MeshBooleanRegistry entry points (boolean,
subtract_many, union_many) already funnel through one private
dispatch, so the pool wraps exactly one call site:

match &self.execution {
    Some(execution) => execution.install(|| execute(provider)),
    None => execute(provider),
}

The context is optional and CpuExecution::install already falls
through when the context was built single-threaded, so the unscoped
path is unchanged. MeshBoolean: Backend is already Send + Sync;
only the dispatch closure needed a Sync bound.

Mutation evidence

The test asserts the pool width the provider OBSERVES at dispatch
time, not that a context was stored. A registry that accepts the
context and ignores it must fail:

Some(_execution) => execute(provider),   -> FAILED
install(|| execute(provider))           -> ok (6 passed)

A negative-control test pins that an unscoped registry still sees
the ambient pool, so the assertion is not vacuously true.

Facade wiring

The facade parallel now reaches dispatch via the WEAK form
axiolid-dispatch?/parallel. Measured on the resolved graph:

• features = [application, parallel] -> axiolid-dispatch feature "parallel" is enabled (this edge did not exist before)
• features = [parallel] alone -> dispatch is NOT pulled in

One honest consequence

The full closure grew by one package. Cargo RESOLVES
axiolid-dispatch for that profile even though it is never linked,
because the weak reference names the optional package. cargo tree
shows nothing; cargo metadata, which the closure gate reads, lists
it. Recorded in the profile with that reason attached rather than
suppressed. All 11 profiles pass and the mutation probe still bites.

The threading page now matches the code, including the previously
uncompilable example.