What

• pn init my_app now creates ./my_app/ and scaffolds app/main.py,
  pythonnative.toml, and .gitignore into it.
• pn init with no name is unchanged: it scaffolds into the current directory,
  named after it.
• The named form refuses when the target directory exists and is not empty,
  unless --force is passed. An existing but empty directory is fine.
• A plain file at ./my_app is always refused, with or without --force.
• The closing hint leads with cd my_app when a name was given.

Why

Closes #21. Every comparable scaffolder (cargo new, create-react-app,
django-admin startproject) creates the directory, and docs/examples.md
already told people to cd my-app after pn init my-app, which didn't work.
Newcomers were surprised to find their working directory filled in.

How (brief)

init_project() resolves a target directory up front and points app/,
pythonnative.toml, and .gitignore at it; everything downstream is
unchanged. Four guards run before any filesystem work:

• the name must be a single directory component, so a path can't be passed as
  a project name;
• the resolved target must be a direct child of the current directory, which
  refuses a symlink at ./<name> pointing elsewhere;
• a plain file at ./<name> is refused, since --force can't turn a file
  into a directory;
• a non-empty target directory is refused unless --force is passed.

--force lifts only the last of these. Every refusal keeps the CLI's existing
Refusing to ... phrasing.

The first two guards deserve a note. Before this change the name argument never
touched the filesystem, so path-like names were harmless: they only fed the
project name and the app id. Now the name resolves to a path, which means
pn init .. --force, or a symlink at ./<name>, would write outside the
current directory. Both are closed here rather than left for a follow-up, since
this change is what introduces the exposure. Worth knowing that Path("..").name
returns "..", so ".." is rejected by name rather than by the component check.

target.mkdir() is never called: app_dir.mkdir(parents=True) already creates
the parent. No new helpers, imports, or dependencies.

Testing

./scripts/check.sh passes locally (Ruff, Black, MyPy, build, pytest, E2E
coverage), and mkdocs build --strict is clean.

New tests in tests/test_cli.py cover the named form creating and populating
./my_app/ with the cwd otherwise untouched, the no-name form scaffolding into
the cwd with a deterministic derived id, the non-empty refusal including that
--force scaffolds over rather than wiping, an existing empty target
succeeding without --force, an existing file refused both ways, path-like
names across seven forms, and symlinked targets with and without --force.

The traversal and symlink tests are mutation-checked: with the relevant guard
removed they fail, and the escape assertions compare the external file
byte-for-byte rather than only counting directory entries, so they pin the
overwrite rather than a side effect of it.

Five existing tests assumed the old layout and now point their follow-up
commands at the created subdirectory, keeping the MyApp argument so the
com.example.myapp derivation stays covered. One of them,
test_cli_doctor_runs, was passing without exercising a scaffolded project at
all, since pn doctor prints its banner and exits 1 even with no config;
retargeting restores what it was written to cover.
test_cli_init_refuses_overwrite needed no change and is untouched.

Risks/Impact

Behavior change for anyone scripting pn init <name> and expecting output in
the current directory: artifacts now land in ./<name>/, so follow-up commands
need a cd or a path. The no-name form is a drop-in.

Docs/Follow-ups

Updated docs/getting-started.md, docs/api/cli.md (both the hand-written
bullet and the mkdocstrings-rendered docstring), CONTRIBUTING.md, and
docs/meta/troubleshooting.md with an entry per new message, following that
file's convention. docs/examples.md needed no change; it already described
this behavior.

Two things I'd rather you(@owenthcarey) decide than assume:

• A trailing separator (pn init my_app/) is rejected by the single-component
  check. Normalizing it would add ambiguity for an argument documented as a
  project name, so I left it strict.
• pn init "my app" passes validation but prints a cd my app hint that won't
  work. Happy to reject such names or quote the hint if you'd prefer.

Separately, and out of scope here: a project name containing a quote or a
control character isn't escaped when written into pythonnative.toml. That
predates this change, since the name always flowed straight into the config.
I can open an issue if it's useful.

Closes #21

Demo