admin judges plugins under the root's one trust builder (harness key included)

[MattJackson]

Bug. The admin side built its own plugin trust policy (crates/busbar-core-admin/src/v1/service_operations.rs trust_policy) for the catalog, install, inspect and rollback. Boot built its policy separately (crates/busbar/src/root/boot.rs trust_policy), and only boot applied the test-harness first-party key override. So in a test-harness build the admin catalog reported a correctly test-signed plugin as REJECTED ... first-party plugin only while boot admitted it. This keeps GetBusbar/busbar-auth-oidc#30's e2e red.

Fix: one builder. root::boot::trust_policy (harness override included) is now the only builder.

• busbar-kernel preflight::RootInstall gains trust_policy: Option<TrustPolicyBuild>. The root installs root::boot::trust_policy in root::linked::register_stores. appbuild copies it onto every App as App::plugin_trust. This uses the existing root-to-kernel channel (ARCHITECT Q8), so it adds no new static seam.
• In busbar-core-admin, the local builder is deleted. trust_policy(app, version) warns about invalid floors, then delegates to app.plugin_trust. With no builder installed it is refused. The 4 call sites now pass &self.app.
• A test build's stand-in is the kernel's existing test_support::trust_policy, adapted as trust_policy_stand_in on STAND_IN. TestApp::plugin_trust(f) lets a test hand in the root's builder.
• Release behaviour is unchanged: the root builder and the old admin builder are the same TrustPolicy::from_config over the same inputs. Only a test-harness build differs.

RED (crates/busbar/src/root/tests/boot.rs):

• a_test_harness_admin_catalog_reads_a_harness_signed_plugin_as_valid, test-harness builds only. The harness variable is set to a key that is not the kernel stand-in's. A plugin that key signed first-party gets valid: true / trust: "trusted" from GET /api/v1/admin/plugins?type=store. Before this fix it read rejected.
• an_admin_catalog_without_test_harness_refuses_a_harness_signed_plugin, builds without the feature: the same plugin is refused (valid: false, rejected).
• In core-admin: every_admin_trust_moment_resolves_through_the_snapshots_builder checks that the admin uses the snapshot's builder and no other. The source pin now asserts the admin source holds 0 TrustPolicy::from_config(.

Draft #971 adds to RootInstall and register_stores as well and will need a rebase. All non-draft PRs touching these files merge clean.

[MattJackson]

Rule 20 note from #1031 (row 155, draft): one disjoint line in root/linked.rs (hot_answer_inline's cap reads busbar_kernel::proxy::max_translate_body_bytes). A test merge is clean.