Gitignored local secrets never reach a spawned workspace, and nothing says so

Summary

A spawned workspace is materialized from source, so gitignored local
credential files do not travel to it. Every project of any size has one
(.env.local, .envrc, config/master.key, secrets.local.toml), and the
result is an instance that cannot do what the main checkout can — with no
error at spawn and no mention in the reference.

Trackers are clearly the intended answer. Nothing says so, and no template
produces one.

What happened

The repo I integrated commits a .env of development defaults and documents
.env.local (gitignored) as where credentials go:

# Committed defaults for local development. Secrets belong in .env.local
# (gitignored), which mise loads after this file and which wins on conflict.

Three separate subsystems read from it: a Shopify API token, the admin API's
CSR_ADMIN_CREDENTIALS, and the off-site backup credentials.

In an instance, all three are simply absent. Starting the admin service in a
spawned workspace:

api-admin: CSR_ADMIN_CREDENTIALS must be a JSON token-to-actor map

Nothing failed at spawn — every resource bound cleanly and reported ok. The
gap only appears later, as a service that will not start, and the reason
("your secrets are in a gitignored file that lives in exactly one checkout")
is several steps removed from the symptom.

Why a tracker is the right answer, and why that is not obvious

A tracker is exactly this: a named lane of file content, audience = "user",
owned outright and kept out of source history. Once you know the tool, the
definition is about ten lines. But:

• newgit resource templates has six templates, including one as specific as
  command-snapshot-migrations. There is no local-secrets equivalent, and
  secrets are a far more universal need than migration-managed databases.
• The tracker section documents the mechanism (audience, paths,
  merge_with_source) without ever naming this as the motivating use case.
  The only worked example in the reference is a deposit-only lane receiving
  database dumps from into_tracker.
• #9 ("Seeding a tracker lane requires round-tripping content through an
  instance") is adjacent and suggests the ergonomics of getting existing
  content into a lane are the remaining friction.

Suggested fix

Either or both:

1. A local-secrets tracker template, or a worked example in the tracker
   reference: "the gitignored file your project's secrets live in, so each
   instance has them without them entering source history."

2. Notice the situation at spawn. newgit knows the workspace's ignore
   rules. A file ignored in the store, present there, and owned by no tracker
   is a strong signal:

   note: `.env.local` exists in the store, is gitignored, and no tracker owns
         it — it will not be present in this workspace.
         `newgit tracker create local-env --audience user` to carry it.
   

   That turns a puzzling service failure hours later into a line at spawn.

Start with the newgit resource templates command, the tracker reference, and the workspace spawn path described in the issue. Read how tracker templates and gitignored files are currently handled, then determine whether the change should provide a local-secrets template, reference example, spawn notice, or a combination. Done means the chosen approach makes gitignored local credentials discoverable and available to spawned workspaces without entering source history.