prepare.cppm: extract P9-P12 (target side, linkage form, scan, fingerprint) as one phase function

Cuts target-side resolution (the layer providers publish once, applied
to every package), #519 per-dependency linkage form, the root and
dependency build.mcpp runs that happen after resolution, the modgraph
scan and validate() pass, and the C++ standard module description into
phase9_target_side_and_scan(PrepareState&). One combined function for
the same reason as P6-P8: the design groups this range into two files
(target_side.cpp, scan.cpp) but the phase-function count itself is not
load-bearing.

Ten more members promoted (fp, stdBmiPath/stdObjectPath/
stdCompatBmiPath/stdCompatObjectPath, describedStdModule,
stdFlagAndDialect, graph_package_entry, scan, report): P13, still
inline in prepare_build's tail, reads the fingerprint and the
compiled/scanned module graph this phase produces. graph_package_entry
is a closure (used for resolution.json's package entries) called again
from deep inside P13.

Found and fixed, by a systematic diff against the last commit rather
than by the compiler alone (these five did not surface as build
errors on the first pass because the corrupted call sites still type-
checked or only failed transitively): the declaration-stripping script
used to promote a member from `Type name = init;` to `state.name =
init;` matched some continuation lines of unrelated multi-argument
calls that happen to read `<identifier>, state.<name>` -- indistin-
guishable from a real `Type name` prefix by the same regex -- and
dropped the leading identifier. Five call sites lost an argument this
way: mcpp::platform::macos::deployment_target's targetIsMacos boolean
(four sites: cAbiTargetIsMacos once, stdTargetIsMacos three times) and
predefines::define_tokens's targetOs. All five were caught either by a
genuine compile error (wrong arity/type) or by re-reading the format
string argument counts; restored from the pre-rename text. A full
diff-based rescan against both the last commit and this step's own
starting point found no further instances of the pattern.

One cosmetic note: this phase function landed textually before phase1
rather than after phase6, because the extraction script's marker
search matched the (identical) line in prepare_build's own forward
declaration rather than the one immediately before its real
definition. Harmless -- nothing calls a phase function before
prepare_build itself does, in order -- but out of the intended reading
order; left for the file-separation step, where each phase becomes its
own translation unit and source order stops being a question.

Golden fixture diff against the baseline is empty; mcpp test: 129/129.

Author: speak-agent