feat(build): mark scaffolded files with //summer:make and pass the app to generated commands (quick-261028-pq8)

- model, migration, command, job and admin-controller stubs start with
  //summer:make <kind>; registry.gen.go keeps its generated-code header
- the registry scan accepts the directive and the older header
- command functions may take one *backpack.App; generatedCommands takes a
  variadic app, so plugin.go files calling generatedCommands() still compile
- scaffolded plugins keep the app from Boot and return generatedCommands(p.app)
- make:command notes the nil app for an older plugin.go
- docs, help text and the blog example follow

docs/setup/porting-a-plugin.md

@@ -183,10 +183,11 @@ func (p *Plugin) AdminControllers() []pact.AdminController {
 	return generatedAdminControllers()
 }
 
-// Commands returns the generated commands plus blog:publish, which needs the
-// database and so is built here with the plugin's withDB.
+// Commands returns the generated commands, which receive the application
+// kept in Boot, plus blog:publish. That one takes the narrower withDB, which
+// its tests replace, so it is added here by hand.
 func (p *Plugin) Commands() []bonfire.Command {
-	return append(generatedCommands(), console.PublishCommand(p.withDB))
+	return append(generatedCommands(p.app), console.PublishCommand(p.withDB))
 }
 
 // AdminFS is the admin YAML the controllers read: controllers/posts and
@@ -575,7 +576,7 @@ class Posts extends Controller
 `summer make:admin-controller acme.blog Posts` writes `controllers/posts.go` and four YAML files. In SummerCMS the controller has no actions or views: the framework's generic admin API lists, shows, creates, updates and deletes records, and the admin SPA draws the screens from the YAML. The controller only says which model it serves, where its YAML is and which permission it needs:
 
 ```go src=docs/examples/blog/controllers/posts.go
-// Code generated by summer make. DO NOT EDIT.
+//summer:make admin-controller
 
 package controllers
 
@@ -726,10 +727,10 @@ class Publish extends Command
 }
 ```
 
-`summer make:command acme.blog Publish` writes `console/publish.go` with a `bonfire.Command` named `blog:publish`. The command needs the database, which only the plugin can reach, so the finished function takes it as a parameter:
+`summer make:command acme.blog Publish` writes `console/publish.go` with a `bonfire.Command` named `blog:publish`, built by a function that takes the `*backpack.App` the plugin kept from `Boot`; through it a command reaches the config and the database. This command takes something narrower instead, a `withDB` function its tests can replace without an application:
 
 ```go src=docs/examples/blog/console/publish.go
-// Code generated by summer make. DO NOT EDIT.
+//summer:make command
 
 package console
 
@@ -779,13 +780,14 @@ the first publication time. It fails when no post has the slug.`,
 }
 ```
 
-Because the function now takes a parameter, the generated accessor no longer lists it; the plugin adds it in `Commands` and passes its `withDB`, which uses the database the server published or, when the command runs from the console, opens one from the application config for the command's duration:
+The generated accessor lists command functions that take no parameter or a single `*backpack.App`, and passes them the application. `PublishCommand` takes `withDB` instead, so the accessor leaves it out; the plugin adds it in `Commands` and passes its `withDB`, which uses the database the server published or, when the command runs from the console, opens one from the application config for the command's duration:
 
 ```go src=docs/examples/blog/plugin.go#Plugin.Commands
-// Commands returns the generated commands plus blog:publish, which needs the
-// database and so is built here with the plugin's withDB.
+// Commands returns the generated commands, which receive the application
+// kept in Boot, plus blog:publish. That one takes the narrower withDB, which
+// its tests replace, so it is added here by hand.
 func (p *Plugin) Commands() []bonfire.Command {
-	return append(generatedCommands(), console.PublishCommand(p.withDB))
+	return append(generatedCommands(p.app), console.PublishCommand(p.withDB))
 }
 ```
 
@@ -819,10 +821,10 @@ See [Writing commands](../console/writing-commands.md) for arguments, flags, pro
 
 The `make:` commands write files that compile, not a finished plugin. These are the steps this walkthrough had to do by hand, and the scaffolder behaviour behind them:
 
-- **The generated-code header stays.** Files the `make:` commands write start with `// Code generated by summer make. DO NOT EDIT.`, although you are meant to edit them. Keep the line: the commands rebuild `registry.gen.go` from the files that carry it, so a model, migration, command or admin controller whose header you delete disappears from the accessors the next time you run a `make:` command. Linters also treat these files as generated and skip them.
+- **The `//summer:make` line stays.** Files the `make:` commands write for you to edit start with `//summer:make <kind>`, such as `//summer:make model`. Keep the line: the commands rebuild `registry.gen.go` from the files that carry it (or the older `// Code generated by summer make. DO NOT EDIT.` header), so a model, migration, command, job or admin controller whose line you delete disappears from the accessors the next time you run a `make:` command. Only `registry.gen.go` itself is marked as generated, so linters check the files you edit.
 - **The admin controller names the model after itself.** `make:admin-controller acme.blog Posts` returns `Posts` from `ModelName` and writes `modelClass: Posts`, and it puts `fields.yaml` and `columns.yaml` under `models/posts/`. Change `ModelName` and both `modelClass` values to the model, `Post`; the YAML can stay where it is, as in this example.
 - **The admin controller needs more than the scaffolder writes.** The generated controller implements only `pact.AdminController`. Add `NewRecord` (`pact.AdminRecordSource`) so the admin API has a model to query, and `RequiredPermissions` (`pact.AdminPermissioned`): without it, any signed-in administrator can open the controller. The model needs `Fillable` and `Rules` before the admin API can save it. The plugin needs `AdminFS` (`pact.AdminAssets`) to embed the YAML; without it the application refuses to start once the admin is enabled.
-- **A command that needs the application takes it as a parameter.** The function `make:command` writes takes no arguments, which is what the generated accessor looks for, so it cannot reach the database or the config. Give it the dependency as a parameter and return it from `Commands` yourself, as `blog:publish` does.
+- **A command with a narrower dependency is added by hand.** The function `make:command` writes receives the `*backpack.App` the plugin kept from `Boot`, and the generated accessor lists such functions. A command that takes something else, such as the `withDB` of `blog:publish`, is left out of the accessor; return it from `Commands` yourself.
 
 ## Checklist