Capability contracts and SDUI ingress

@fabricorg/gen-capability emits registry-ready usage contracts from explicit manifest capability metadata plus derived actions, schemas, events, and views. @fabricorg/gen-sdui emits data-shape bindings such as capability://module/summary; it does not own screens, themes, or a composer.

Core manifest capability metadata declares permissions, entitlements, flags, certification, required ports, and namespaced JSON extensions. @fabricorg/experience-contracts defines the optional fabric.experience/v1 extension for roles, slots, action intents, and display rendering. Platform preserves but does not interpret those experience semantics. Port requirements reference an established standard where one exists—for example OpenFeature for flags—rather than inventing parallel semantics. Actions use ActionExecutionContract to declare portable execution semantics such as offline eligibility, governing authority moment, completion, consistency, idempotency stance, and sensitivity. Views declare semantic usage, collection, freshness, offline usability, and classification. None of these fields describes layout or pixels.

The serialized governingMoment qualifier records whether capture time, execution time, or both govern authority; implementations bind that declaration to the Host's AuthorizationBinding checks rather than treating an offline document as continuing permission.

An SDUI action enters through an authenticated application dispatcher and then createGovernedActionHost(). Human dispatches use natural_person; agent dispatches use agent. Both use trusted tenant/actor context and the same validation, policy, state-machine, durable invocation, handler, adapter, event, and audit pipeline. There is no direct-handler ingress.

@fabricorg/adoption-bindings validates a vertical's adoption binding against that published contract at build time: every declared role bound, bound components resolving and declaring the role they fill, slot fills naming declared slots and resolving to real views, action overrides targeting declared intents, and data maps naming published views and existing fields. validateBinding returns every finding rather than the first; assertBindingValid throws with each unsatisfied path named, for use as a build step. It is build-time tooling: no runtime package has a concept of a binding.

@fabricorg/ports supplies the interface behind a declared port requirement, which otherwise resolves against nothing. FlagsPort is structurally compatible with an OpenFeature provider's evaluation surface and DesignTokensPort consumes W3C DTCG documents, so the incumbent vendor is one provider behind the interface rather than a coupling. assertPortRequirementsSatisfied turns a capability's declaration into a deployment gate naming every unsatisfied port, and flagsPortChecks/designTokensPortChecks are the suite every adapter must pass before it can replace another. No package here imports a vendor SDK.