Relax setup-composer fallback runtime install to work without composer.lock

[coisa]

Problem

Consumer repositories that use the shared .github/workflows from php-fast-forward/dev-tools fail to run CI when the fallback DevTools runtime path has no composer.lock.

Current Behavior

When setup-composer executes fallback installation with ramsey/composer-install, the step uses require-lock-file: 'true'. In repos like php-fast-forward/agents there is no committed composer.lock in the workflow-checkout copy (.dev-tools-actions), so CI emits an error such as:

• ##[error]Unable to find 'composer.lock'

The issue surfaces in reusable workflows that call ./.dev-tools-actions/.github/actions/php/setup-composer (for example tests, changelog, reports, auto-resolve-conflicts).

Expected Behavior

setup-composer should support lockless runtime setup for the fallback DevTools bootstrap and keep CI green without requiring composer.lock to be present in consumer repositories.

Failure Surface

• Workflow calls that reuse php-fast-forward/dev-tools shared workflows
• .github/actions/php/setup-composer/action.yml
• ramsey/composer-install invocation inside Install fallback DevTools runtime
• composer.lock absence in checked-out workflow source trees

Proposal

Make fallback Composer install in the shared action tolerant of repos without a committed lockfile.

Potential safe correction:

• Set require-lock-file to false for the fallback install in setup-composer when running consumer fallback path.
• Keep lockfile enforcement intact for normal project dependency installs where composer.lock is already expected.
• Document/align this behavior so lockless shared-workflow execution remains deterministic and non-blocking.

Implementation Strategy

1. Update .github/actions/php/setup-composer/action.yml to avoid strict lockfile requirement during fallback runtime install.
2. Add/adjust targeted assertion that the workflow can run when .dev-tools-actions is checked out without composer.lock.
3. Verify by running affected workflows in a lockless consumer repository.

Non-goals

• Changing primary dependency-resolution behavior for consumer project installs.
• Introducing a global lockfile policy for this repository bundle.
• Refactoring the overall action architecture beyond this focused compatibility fix.

Acceptance Criteria

Functional Criteria

• Reusable workflows in a repository without composer.lock no longer fail at setup-composer fallback install.
• tests, changelog, reports, and auto-resolve-conflicts can execute through the shared workflow path.
• No new requirement is introduced to commit composer.lock in this repository to satisfy CI.

Regression Criteria

• Existing behavior remains unchanged for repositories that keep lockfiles.
• The fix is covered by a focused regression test or documented CI check that reproduces lockless fallback usage.

Architectural / Isolation Criteria

• The CLI/workflow entrypoint remains orchestration-only while domain behavior stays deterministic and testable.
• Exit behavior and setup failure modes remain explicit and debuggable.