feat(turbo-generators): feature scaffold registers in release-please

Closes the user's gap: when `pnpm turbo gen feature <name>` scaffolds
a new feature, that feature must also be tracked by release-please —
otherwise it sits outside the versioning + changelog pipeline.

The generator now performs three release-please integrations:

1. **CHANGELOG.md seeded at v0.1.0** — new template at
   templates/feature/CHANGELOG.md.hbs emits a baseline entry pointing
   at ADR-021 + docs/guides/releasing.md so the consumer immediately
   sees where future entries will appear.

2. **package.json version field bumped** — templates/feature/
   package.json.hbs: "0.0.0" -> "0.1.0", matching the per-feature
   baseline established when release-please was set up.

3. **Manifest + config registration via a new custom action** —
   lib/release-please-utils.ts exports
   registerFeatureInReleasePlease(repoRoot, name) which:
     - Reads .release-please-manifest.json, adds
       `"packages/<name>": "0.1.0"`, writes back with sorted keys
       (root stays first, rest alphabetical) so diffs stay minimal
     - Reads release-please-config.json, adds the per-package config
       block (package-name, component, changelog-path), writes back
       with the same sort
     - Idempotent — re-running on an already-tracked feature is a
       no-op
     - Throws fast if either file is missing (ADR-021 requires
       release-please to be set up BEFORE features can register)

The generator wires this in via a function action between the last
file `add` and the next-steps printout. Its return string surfaces
in the generator log so the user sees "Registered @repo/<name> in
release-please tracking".

Tested: 5/5 unit tests cover the happy path, idempotency, sort
order, and both missing-file error paths. Smoke-tested against the
real repo configs (adding a synthetic "demo" feature, then
restoring) — manifest entry appears in the correct sorted position;
config block has the right shape.

Future `pnpm turbo gen feature` invocations cannot leave a feature
untracked. Existing features (auth, blog, media, marketing-pages,
navigation) were registered manually when the release-please epic
landed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

turbo/generators/config.ts

@@ -10,6 +10,7 @@ import {
   addBoundariesEntry,
   emitTemplateTree,
 } from "./lib/core-package-utils.js";
+import { registerFeatureInReleasePlease } from "./lib/release-please-utils.js";
 
 /**
  * Turbo generator: `feature`
@@ -306,6 +307,30 @@ export default function generator(plop: PlopTypes.NodePlopAPI): void {
         templateFile: "templates/feature/src/ui/index.ts.hbs",
       },
 
+      // CHANGELOG (release-please will append future versions; v0.1.0 seed)
+      {
+        type: "add",
+        path: "packages/{{kebabCase name}}/CHANGELOG.md",
+        templateFile: "templates/feature/CHANGELOG.md.hbs",
+      },
+
+      // Register the new feature in release-please tracking (ADR-021).
+      // Adds an entry to .release-please-manifest.json and a per-package
+      // block to release-please-config.json. Idempotent + sorted so reruns
+      // are stable. Throws if either file is missing.
+      function registerInReleasePlease(
+        answers: Record<string, unknown>,
+      ): string {
+        const a = answers as { name: string };
+        const repoRoot = process.cwd();
+        const { manifestChanged, configChanged } =
+          registerFeatureInReleasePlease(repoRoot, a.name);
+        if (manifestChanged || configChanged) {
+          return `Registered @repo/${a.name} in release-please tracking (manifest + config)`;
+        }
+        return `@repo/${a.name} already tracked by release-please (no changes)`;
+      },
+
       // Final manual-wiring instructions printed to the user
       function printNextSteps(answers: Record<string, unknown>): string {
         const a = answers as {