feat: add onPluginsReady callback to createApp, remove autoStart

[MarioCadenas]

Summary

• Adds an onPluginsReady lifecycle hook to createApp that runs after plugin setup but before the server starts, replacing the autoStart: false + .extend() + .start() ceremony
• Server start is now orchestrated by createApp (looks up "server" plugin by name), making autoStart and manual start() unnecessary
• Removes autoStart from public API (ServerConfig, DEFAULT_CONFIG, manifest) and start() from server exports
• Adds appkit codemod customize-callback CLI command to auto-migrate existing apps
• Adds runtime detection that throws helpful errors directing users to the codemod

Before / After

Before:

const appkit = await createApp({
  plugins: [server({ autoStart: false }), analytics({})],
});
appkit.server.extend((app) => {
  app.get("/custom", (_req, res) => res.json({ ok: true }));
});
await appkit.server.start();

After:

await createApp({
  plugins: [server(), analytics({})],
  onPluginsReady(appkit) {
    appkit.server.extend((app) => {
      app.get("/custom", (_req, res) => res.json({ ok: true }));
    });
  },
});

Migration

npx appkit codemod customize-callback --write

Auto-detects server entry files and rewrites both .then() chain and await + imperative patterns. Dry-run by default (omit --write to preview).

Test plan

• All existing tests updated and passing (1569/1569)
• New integration tests for onPluginsReady (sync, async, without server plugin)
• Codemod tests: Pattern A, Pattern B, bail-out, idempotency, autoStart stripping
• Runtime detection tests: constructor throws on autoStart, exports().start() throws
• Typecheck passes
• Build passes
• Biome lint passes on changed files

[atilafassina]

I think this is a step in the right direction and we should have this ASAP.
We did a quick search on other server frameworks out there and owning the lifecycle of plugins simplifies things a lot in orchestrating functionality and avoiding race conditions. Removing the autoStart config is just a user-facing bonus of having a more reliable architecture beneath it.

That being said, as we talked on Slack (just surfacing this here), the API name could change. customize doesn't really translates to the user only the intent, not what it's doing (and more importantly when), makes it less intuitive and discoverable. customize should be split in pre() and post() hooks, running respectively before and after plugin instantiation.

The use case we need to cover immediately is pre(), so I think just renaming this here and shipping this incrementally would be great already, we cross the post() bridge when we get there perhaps - who knows, maybe we need more hooks in the future as our typegen/compiler story evolves.

[atilafassina]

[nit] I tend to prefer deprecation messages that offer an alterantive instead of just saying the thing is gone. So perhaps extend this note saying we have a lifecycle hook to run when plugin is loaded. We can use the @example keyword to offer the syntax and boost self-discoverability of the new feature.

[atilafassina]

[take it or leave it]
considering this is an "advanced-level" feature, an info level log when on dev could boost debuggability