An installed app can migrate its own type into a commons type #416

Problem

A custom type can "graduate" into a commons type: migration(MyNoteV1, NOTE, fn) builds a typed step across families, and migrateAll(MyNoteV1.baseId) commits it (see data-model.md § Type migrations, and #407 / #415, which keep lineage inside a family so this step needs nothing from the commons handle).

That works when the owner runs it. An installed (contained) app can't, because apps.md § Migrating an installed app's types admits an app's migration commit only when both the source and target families are in its own namespace and in its defines. A commons family never is, so POST /records/:id/migrate into it is refused, and graduation needs the owner to run the app's migration code with owner authority — the gap installs exist to close.

What needs deciding

• How the app asks. For example, a manifest entry naming the source family and the target family ("migrate from com.example.app/note into org.haverstack/note"), which planInstall() shows the owner like any other request.
• What the owner approves. The target is a family the app doesn't define, so defines can't carry it. Should approval name a target version, or the family? Does the app need a grant on the target family (create/update-any), and through which kind of grant?
• What stays refused. The existing migration checks (DID bindings, _attachment, no migration into _group, the file-reference gate) apply as they do today. Whether a contained app may migrate out of a family it doesn't own is out of scope: this covers only from its own family into another.

Actions

• Decide the manifest shape and the plan entry the owner sees.
• Extend the admission rule in apps.md § Migrating an installed app's types and ScopedStack.commitMigration().
• Conformance fixtures for an admitted and a refused cross-family commit over the wire.
• Spec: apps.md, and the commons guide's "Migrate in later" step (docs/commons/README.md), which today only works for the owner.