Phase 9 cleanup: remove back-compat 2-arg ctors on Box migration runners

[iancooper]

Context

PR #4039 introduces the Box Provisioning module. All five backend
migration runners currently expose two constructors:

• A 5-arg (or 3-arg, on Spanner) ctor taking an explicit
  IAmA{Backend}BoxDetectionHelper plus the other dependencies.
• A 2-arg (or 3-arg, on Spanner) back-compat ctor taking the
  configuration + lock timeout, marked with inline comments stating
  "removed when DI cascade lands in Phase 9".

Files:

• src/Paramore.Brighter.BoxProvisioning.MsSql/MsSqlBoxMigrationRunner.cs — 5-arg + 2-arg back-compat
• src/Paramore.Brighter.BoxProvisioning.MySql/MySqlBoxMigrationRunner.cs — 5-arg + 2-arg back-compat
• src/Paramore.Brighter.BoxProvisioning.PostgreSql/PostgreSqlBoxMigrationRunner.cs — 5-arg + 2-arg back-compat
• src/Paramore.Brighter.BoxProvisioning.Sqlite/SqliteBoxMigrationRunner.cs — 5-arg + 2-arg back-compat
• src/Paramore.Brighter.BoxProvisioning.Spanner/SpannerBoxMigrationRunner.cs — 3-arg + 3-arg back-compat

What needs doing

When Spec 0027's DI cascade lands and the explicit-detection ctor is
the universal call shape, drop the back-compat constructors from all
five runners. git log --grep="Phase 9" is the tracking pointer.

Why this is a follow-up, not part of PR #4039

Spec 0027's DI surface has not yet shipped; removing the back-compat
ctors now breaks any downstream consumer using the older signature on
upgrade. The reviewer on PR #4039 flagged this as worth doing but
acknowledged the natural deferral.

Acceptance

• Back-compat ctors removed from all five runners.
• Inline "Phase 9" comments removed.
• Tests updated to use the explicit-detection ctor only.
• No behaviour change beyond the smaller constructor surface.

Reference

PR #4039 review comment:
#4039 (comment)

🤖 Generated with Claude Code