Play Framework

fix(cli): reject a flag in the `play new` name position (PF-167)

`play new --frontend` scaffolded a directory literally called "--frontend" —
and, since the identifier is derived by stripping non-alphanumerics, an app whose
rootProject.name was "frontend" with no Nuxt frontend in it, because the flag was
consumed as the name and never reached the option loop.

The guard only tested for a *missing* argument:

    APP_NAME="${1:-}"
    if [ -z "$APP_NAME" ]; then ...

"--frontend" is a non-empty string, so it passed, became APP_NAME, and was
shifted away before the `for arg in "$@"` loop could see it. Same for any flag in
that position, e.g. `play new --dest=/some/path`.

Now a flag-shaped first argument takes the same branch as a missing one and
prints the existing "missing application name." + usage. Requiring the name first
matches the documented usage string, so no supported invocation changes.

Scoped to `new`: it is the only subcommand reading a positional first argument
this way (APP_NAME="${1:-}" is the sole occurrence in the shim); the others route
everything through the generic option loop.

Not a recent regression, despite appearances — `git log -S"missing application
name" -- play` shows the guard arrived with the 1.13 wrapper in b26c584a1 (PF-90)
and was never modified, so it has been empty-only for as long as --frontend has
existed.

Verified:
  play new --frontend        -> error + usage, exit 1, nothing created
  play new --dest=/tmp/x     -> same guard
  play new                   -> unchanged
  play new NAME --frontend   -> still scaffolds, frontend/ generated
  play new NAME --dest=PATH  -> still scaffolds at PATH

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>