core: simplify the Kubb class and settle the builder-pattern question

## Context The `Kubb` class resolves config inside `setup()` today, which forces a `#config: Config | null` field and getters for `config`, `storage`, and `driver` that throw before setup runs. `resolveConfig` is pure and synchronous, so it can run in the constructor instead. This issue also settles the question that keeps coming up: should `createKubb` use a fluent builder? No. 1. Every real consumer (the CLI, unplugin, mcp, the platform agent) passes a plain, serializable config object that `defineConfig` produces in `kubb.config.ts`. A builder cannot live in a config file, so it would add a second, imperative way to say the same thing. 2. Cache fingerprinting (`Fingerprint.compute({ config })`, `KubbDriver.ts:389`) and the JSON schema we ship both need config to stay plain data. 3. The class is already about 90 lines. A builder adds a concept when the goal is to remove them. The surface stays as it is: `constructor`, `hooks`, `config`, `storage`, `driver`, `setup()`, `build()`, `safeBuild()`, `dispose()`. Public `setup()` stays because the CLI, unplugin, mcp, and the platform agent all call it to bracket progress events. `build()` stays because real callers use it: the plugins-repo `scripts/build-extension-yaml.ts:151`, `examples/client/build.ts:19`, and `tests/performance/main.bench.ts`. ## Tasks - [ ] Resolve config in the `Kubb` constructor. The `config` getter stops throwing and the nullable field goes away. `setup()` keeps only the async work: `setMaxListeners`, the `output.clean` storage clear, and `driver.setup()`. - [ ] Remove the now-dead `kubb.config ?? userConfig` branch in `packages/unplugin-kubb/src/unpluginFactory.ts:105`. - [ ] Note in the JSDoc that `safeBuild()` is the canonical call. ## Verification `pnpm lint && pnpm typecheck && pnpm test` in the kubb repo, where `createKubb.test.ts` covers the lifecycle. Rebuild the plugins-repo examples and expect byte-identical output.