Converge the public API on one naming and typing convention

[AlexSkrypnyk]

Summary

ApiServerContext spells the same idea 4 different ways across its public step methods, and 2 of its constructor-facing details are inconsistent with the rest of the library. All 3 are breaking to change, so 3.0 is the opportunity.

Details

Step method naming

The 9 public step methods use 4 different shapes for the same "this is an API server thing" idea:

Shape	Methods
api prefix	apiIsRunning(), apiHasNoResponses(), apiWillRespondWith(), apiWillRespondWithJson(), apiWillRespondWithFile()
Api suffix	resetApi()
Api infix	debugApiRequests()
no token, assert prefix	assertQueuedResponsesCount(), assertReceivedRequestsCount()

The api prefix is the clear majority at 5 of 9. The 2 assert* methods are arguably a separate family and a case can be made for leaving them - they read fine and the prefix says what they do. resetApi() and debugApiRequests() are the real outliers.

This is breaking because these are public methods of a published class. Consumers can call them directly or override them in a subclass, and the README documents resetApi and apiWillRespondWithFile by name. The Gherkin step phrases in the annotations are a separate contract and should NOT change with the method names - consumers' .feature files depend on the exact wording, and there is no reason to make them rewrite feature files over an internal rename.

Untyped $paths constructor parameter

public function __construct(
  ...
  $paths = NULL,
) {

$paths is the only untyped parameter in src/. The docblock says string[]|string|null. Adding the native union narrows what the published constructor accepts, which is the breaking part: values that currently coerce, such as a YAML integer that strval() happily turns into a string, would become TypeErrors.

Note the parameter name itself is wired from consumers' behat.yml as the paths: key, so the name must not change even if the type does.

$debug names both a property and a method

PhpServerContext has a promoted public constructor parameter $debug and a protected method debug(). They are unrelated, and $this->debug versus $this->debug() is a real source of misreading. The property name is fixed by behat.yml, so any fix renames the method.

There is a decent argument for leaving this one alone. Worth deciding rather than defaulting.

Scope note

Companion to #103, which already covers Behat 4 support and dropping PHP 8.2. Doing the naming break in the same major means consumers migrate once.

Whatever lands here needs a migration note in the README or a dedicated upgrade section: old name to new name, and an explicit statement that step phrases are unchanged.