feat(init): ignore generated files and make the example visible

[refsz]

Re-target of #38, whose content never reached main - it merged into ci/harden-release, which #36 had already squashed away. Same commit, cherry-picked onto main, no changes to it; #38 needs no further action.

That is the third time today (#31, #34, #38). The warning I put at the top of #38 did not prevent it, because the cause was stacking the branch at all, not a missing note. I will not open another PR against a non-main base for this repo - if two changes touch the same lines, the second waits for the first to merge.

Three things a fresh sputnik init got wrong. I found them by running the built PHAR as a user would while checking the release path for #36.

The scaffold staged generated code for the user's first commit

init never wrote a .gitignore. Nette compiles the container into .sputnik/cache on the very first run, so git add . in a fresh project picks up generated PHP with absolute paths in it. .sputnik.neon - the local, uncommitted override of the committed .sputnik.dist.neon - had the same problem.

init now ensures both entries:

• no .gitignore → creates one with the two paths
• an existing .gitignore → appends only what is missing, under a # Sputnik comment, never rewriting what is there
• already covered → touches nothing, byte for byte

All three paths are tested, including the "leaves it alone" case, which is the one that would quietly clobber someone's file if it broke.

The example task printed one of the three lines it appeared to print

$ctx->success("Hello, {$name}!");
$ctx->info("App: {$appName}");
$ctx->info("Context: {$context}");

info() is a logger call, visible only with -v. A user running sputnik example for the first time saw Hello, World! and nothing else, from code that plainly looks like it prints three lines. That reads as broken, and it is the first thing anyone runs.

The two are writeln() now. One info() stays, with a comment saying what it is for - the distinction between output and logging is worth learning at that moment rather than discovering by confusion.

The scaffolded config never mentioned either 0.2 feature

The file the user is told to edit now carries commented examples for variables.secrets and environment.executor, so the two things a project most often needs next are named where they will be seen. Both are comments, so the config still validates as-is.

Verified on this branch

vendor/bin/phpunit          747 tests, OK
vendor/bin/phpstan analyse  [OK] No errors
vendor/bin/php-cs-fixer     0 of 153 files

🤖 Generated with Claude Code

https://claude.ai/code/session_018CTvnzcNYmFgm2HQcm821A