docs: architecture review of toolchain origins, selection and distribution

Written from the round that actually got `msvc@<toolset>` working: nine
layers of defect, five index publish windows, three tests that could not
fail. Every finding is anchored to a file:line, not a preference.

The two-axis model (acquisition vs resolution) is right and nothing here
proposes replacing it. The findings are all one sentence: that axis exists
only for MSVC, and it is only carried half way.

Ten findings, including three that are live defects rather than design
debt:

  - doctor.cppm:398 still uses the pre-#436 `toolchain_frontend(root/"bin")`
    shape, so an installed msvc toolset is visible to `toolchain list` and
    invisible to `doctor`. One line.
  - a /MD build with a managed toolset links vcruntime140.dll, which is not
    an OS component and appears nowhere in src/ -- on a clean Windows box
    `mcpp build` succeeds and `mcpp run` cannot start. CI hides it by having
    Visual Studio installed.
  - `has_usable_msvc()` probes the machine but gates three decisions that
    also apply to managed toolsets, so a box with a pinned toolset and no VS
    answers "no MSVC here".

And the largest structural gap: `mcpp pack` is ELF-only, and
distribution.cppm's contract never reaches pack.cppm at all, so
`cxx_runtime` has no enforcer at packaging time on either platform.

Author: speak-agent