Statically linked libphosh

[samcday]

Support building phrog against either an installed shared libphosh or an explicitly embedded copy of the vendored Phosh sources. This lets us carry and validate downstream fixes while retaining the normal distribution-library workflow.

Current policy: dynamic linking remains the default (cargo build). cargo vendored-phosh <command> opts into embedding. There is no committed release version or decision to switch Alpine/Fedora package defaults to embedding; those are separate packaging decisions.

Implementation is split into #211 (pristine GTK3 subtree imports) and #186 (opt-in embedding and development commands), in stack #214. Both linking modes must be validated. Source updates use git subtree --squash, preserving merge parents/trailers and keeping downstream patches separate.

GTK4 is an independent, long-running development series above this base: #213 imports Guido's Phosh GTK4 work and #209 ports phrog and the Rust bindings. main continues GTK3 stable releases; the GTK4 migration is tracked separately in #215. Embedding helps build the unreleased GTK4 libphosh ABI, but the GTK4 migration neither replaces this proposal nor makes static linking mandatory.

• Provide explicit dynamic and embedded build interfaces.
• Preserve real subtree imports and document the update/export workflow.
• Validate both GTK3 modes locally in Add opt-in static libphosh embedding for GTK3 #186 and both GTK4 modes locally in gtk4: migrate phrog and Rust bindings #209.
• Finish review and land the GTK3 layers independently of GTK4.
• Keep both linking modes passing in CI as dependencies and downstream patches change.
• Resolve packaging/install details and choose any downstream default changes separately (including phrog schema handling in Custom schemas directory #184).

Resource registration remains a downstream patch, following the decision to close #210. Embedded libphosh still relies on shared GTK/native libraries and runtime data; this is not a fully static standalone executable.