[ci18-7277] Detect the layout in the action, so api-token is the only input

[pavel-te]

Why

The on-ramp promises copy-paste, and it was not keeping that promise. The input gate rejected a call carrying only api-token, so every snippet the product printed had to spell out source-locale + patterns — meaning the user typed a path by hand, or the product guessed one and showed a placeholder that looked like a detected value.

The machinery to avoid that already shipped: ptc-cli is vendored inside this action, ptc init needs no token (ci18-7276), and detect_config answers anonymously (ci18-7247 / ci18-7275). Nothing was missing except wiring them together here.

What

Resolution order, first match wins:

1. config-file — an explicit path the caller passed
2. .ptc-config.yml — one committed to the repository
3. source-locale + patterns — spelled out inline
4. nothing — run ptc init right here and use what it writes

Minimal call becomes:

- uses: OnTheGoSystems/ptc-action@v1
  with:
    api-token: ${{ secrets.PTC_API_TOKEN }}
    create-pr: true

A layout the classifier does not recognise still writes a config — a commented template with no files: block. The action checks for that and fails with the reason and the way out, instead of letting the CLI stop on a config it cannot use.

Verified against production (act)

Minimal call — detection fires and the run completes:

No config and no source-locale/patterns — detecting the layout with `ptc init`.
Detected layout:
  source_locale: en
    - file: locales/en.json
      output: locales/{{lang}}.json
...
inflating: locales/de.json
inflating: locales/ru.json
Job succeeded

Explicit patterns — detection is skipped entirely, behaviour unchanged. No regression.

Self-test now also asserts the three inputs stay optional and that the action can detect on its own.