docs: clarify first project run steps

[bartlomieju]

This tightens up runtime/getting_started/first_project.md so that a reader
following along from a clean shell can actually run the freshly initialized
project without hitting a confusing error.

Previously the page ran deno init my_project and then jumped straight to
deno main.ts, which fails from the parent directory because main.ts
lives inside my_project/. An explicit cd my_project step is now shown
between init and run so the example works end to end.

The page also explained the main.ts contents with an "As of Deno 2.8…"
preamble, which silently goes stale every time a new release ships. The
sentence has been rephrased to describe what main.ts contains without
anchoring to a particular version, so the doc doesn't need a yearly bump.

While reading the run section it wasn't obvious why deno main.ts works
without an explicit run subcommand. A single sentence has been added
next to the first example noting that Deno infers run when given a file
path, which should head off the "is this a typo?" reaction from newcomers.

The brittle deno test output block listing specific test names
("handler returns hello", etc.) was considered but left as-is: the
specific names still carry real pedagogical value by showing readers
what's being tested against the handler, and the deno init template
changes rarely enough that the drift risk is low. Happy to soften it in
a follow-up if reviewers disagree.

Ran deno fmt on the file after editing.

[fibibot]

1. deno main.ts drops the network permission needed by the generated HTTP server. The current Deno 2.8.1 deno init template prints deno run --allow-net main.ts; without --allow-net, Deno.serve(handler) cannot bind without prompting/failing in non-interactive runs. Use deno run --allow-net main.ts here, and keep the shorthand explanation only if it also mentions permissions.