Adopt shared Scala CI workflow

[stasimus]

Replaces the hand-written ci.yml with a call to the shared workflow. Defaults match what this repo already did, so no inputs are needed.

Red for two reasons, both pre-existing and both needing a maintainer decision rather than a workflow change — see the comment below.

Part of evolution-gaming/scala-github-actions#5

[stasimus]

The two failing legs are a true positive, not a regression from this change.

versionPolicyCheck fails on clean master with no coverage involved:

[error] Module smetrics-doobie:2.5.0+9-f5b6dc21 is not binary compatible with smetrics-doobie_2.13:2.5.0
[error]    * static method apply(doobie.util.transactor#Transactor, ...) type is different in current version,
           where it is (org.typelevel.doobie.util.transactor#Transactor, ...)
[error] Incompatibilities with dependencies of smetrics-doobie:2.5.0
[error]   org.tpolecat:doobie-core_2.13: missing dependency

doobie moved its packages to org.typelevel.doobie.*, so smetrics-doobie really did break binary compatibility.

Current CI misses it because actions/checkout runs with the default fetch-depth: 1. Without tags sbt-dynver computes 0.0.0+1-f5b6dc21, so there is no previous version to compare against and MiMa passes vacuously. The shared workflow checks out with fetch-depth: 0, so the check actually runs.

Options, all outside the scope of this PR: add ProblemFilters.exclude[IncompatibleMethTypeProblem]("com.evolutiongaming.smetrics.TransactorMetered.apply"), uncomment the doobie-core % VersionScheme.Always entry in libraryDependencySchemes, relax versionPolicyIntention, or set version_policy_check: false here and fix it separately.

[stasimus]

Both failures are pre-existing, and neither should be papered over from this PR.

SmetricsBackendSpec (3.3.8) already fails on master. Run 30695420248 on master fails with the identical assertion, Vector(1, 2, 4, 5, 6) was not equal to List(1, 2, 3, 4, 5, 6) at SmetricsBackendSpec.scala:79. Master has been red since #440. Same values every time, so this looks deterministic rather than flaky.

versionPolicyCheck (2.13.18) surfaces a genuine binary incompatibility. smetrics-doobie is not binary compatible with 2.5.0 because doobie moved package, doobie.util.transactor.Transactor → org.typelevel.doobie.util.transactor.Transactor, changing the signature of TransactorMetered.apply. org.tpolecat:doobie-core_2.13 and doobie-free_2.13 are also reported as missing dependencies.

This was never caught before because the old ci.yml checked out shallow: without tags sbt-dynver reports the version as 0.0.0, so MiMa had no previous artifact to compare against and the check passed vacuously. The shared workflow uses fetch-depth: 0, so it now actually runs.

Making it green means declaring what the next release intends — most likely versionPolicyIntention := Compatibility.None if the doobie package move is accepted as breaking, or MiMa exclusions if smetrics-doobie is considered exempt. That is a versioning call for this repo, so I have left the PR red rather than choosing.