When a test database already exists and is non-empty (created by a prior
step like `I have initialized a project`), _fast_init_or_upgrade in
features/environment.py was falling through to _original_init_or_upgrade,
running a full Alembic migration version check every time. This created
redundant SQLAlchemy engines, caused SQLite lock contention under
parallel execution, and triggered cumulative overhead from @database_retry
decorators (wait_fixed(0.5) × 3 attempts on ~100 repository methods),
leading to intermittent hangs and CI timeouts.
The fix changes the existing-non-empty-database branch to return
immediately instead of delegating to the original migration runner.
This is safe because test databases are either template-copied (already
at Alembic HEAD) or created by a prior step that already ran the full
migration. The _SCENARIO_DB_PREFIXES guard ensures non-scenario
databases (migration-runner unit tests) remain unaffected.
Verified: 15/15 scenarios pass with both --processes 1 and --processes 16.
ISSUES CLOSED: #726
CoreRasurae
