refactor(agent)!: remove packages, manifests, and fork

[Yevanchen]

Outcome

Remove Agent Package, portable Manifest, and Fork product lifecycles from Mosoo main. Retain the smallest saved private Agent configuration used by the Session API. This follows #582 and precedes #584.

Remove

• Package import/export, package downloads/uploads, format-version negotiation, and portable manifests.
• Fork mutations, target-Type conversion, package provenance/distribution metadata, and reachable compatibility parsers or tombstone endpoints whose only purpose is accepting removed packages.
• Product/API/UI flows and generated contracts for those capabilities. Do not replace them with a new distribution format.

Retain

• Project-private saved instructions, Skills, existing MCP references, and necessary ownership checks.
• Calling a private Agent by ID; each new Session resolves latest saved configuration.
• Internal immutable configuration snapshots for admitted Sessions and promised historical records. Updating an Agent must not alter an existing Session's configuration.
• Managed Agent selection and private Agents entering the same Session execution path.

There is no public revision selector. Do not require callers to copy revision references, invoke historical revision 1/2 explicitly, or retain workers for historical configurations.

Acceptance criteria

• Package import/export/download, portable manifests, and Fork are absent from active product, API, generated clients, and UI.
• A Project can save a private Agent and invoke it immediately by Agent ID without Publish.
• Updating that Agent affects a new Session while an existing Session continues with its admitted configuration.
• Internal snapshots and promised history remain readable; removal does not delete user files or history implicitly.
• No package compatibility runtime, replacement distribution format, public version selector, or Pet/Cattle conversion path remains.
• Focused tests cover ownership, configuration retention across edits, and removal of old entrypoints.
• Data inventory, cutover, rollback, and applicable Cloudflare notification evidence are complete before closing the shipped issue.

Billing, balances, subscription routing, invoices, and BYOK settlement are outside this issue.

Delivery and migration

The current contract is SPEC on main, with the shipped direct Project-owned durable Session baseline recorded in #582. PR #622 was closed as superseded; it is historical context, not the current delivery specification. This issue remains open for the cleanup and acceptance below; #582's release does not establish that this cleanup shipped. Preserve the owner-approved same-Session continuation semantics for replies seconds or days later. Earlier issue text and comments do not reintroduce historical-version invocation, interactive approvals, or typed Git infrastructure into v1.

Intentional breaking changes are accepted with an explicit cutover, treatment of admitted work, preserved promised history, compatible clients, and a rollback point. Production D1 remains append-only. Destructive or data-rewrite operations require separate explicit approval, backup, verification, and rollback procedures. Prepare the affected audience and migration notice before release; use Cloudflare Email Service and reconcile sending outcomes plus sample inbox/content verification. The completed #581 key notice does not cover later Session or Builder changes. Documentation updates do not authorize a production deployment or trigger a new email.