2.1.86 shipped Dapper.StrongName and Dapper.EntityFramework.StrongName with an
all-zero strong-name signature, so they fail strong-name validation when loaded
on .NET Framework. Comparing the shipped assemblies:

  2.1.79  sig 128B, nonzero=127  real signature
  2.1.86  sig 128B, nonzero=0    public-signed only

Both projects carried

  <PublicSign Condition=" '$(OS)' != 'Windows_NT' ">true</PublicSign>

Public signing stamps the public key and sets the STRONGNAMESIGNED flag but
writes no actual signature: the assembly claims to be strong-named and is not.
.NET Core and later do not verify strong names, so only .NET Framework consumers
see the failure.

The condition never fired in practice because releases were packed by hand on
Windows. release.yml now builds on ubuntu-latest, so it fires on every release -
this is a regression introduced by #2230, not by anything in the signing setup.

The condition is a legacy workaround from when Roslyn could not fully sign off
Windows; it can now. Removing it rather than moving the release job to Windows
fixes the cause instead of avoiding it, and keeps a Linux developer build honest
too. Verified on Linux: a full Build.csproj pack produces real 128-byte
signatures for every TFM of both packages.

Dapper.snk is unchanged - untouched since the commit that added Dapper.StrongName
- so the public key token is identical and this is a signature fix, not an
identity change. Windows builds are unaffected: the condition was already false
there.

…2238)

main.yml filtered pushes with

  paths:
  - '*'
  - '!/docs/*'

GitHub's `*` does not cross a '/', so `'*'` matches only files at the repository
root. Any push touching just Dapper/, tests/ or another subdirectory failed the
filter and the build was skipped - silently, because a skipped workflow is not a
failure. Checking main:

  8becae8 (#2230)  4 root files  ran
  2ca8261 (#2223)  1 root file   ran
  6d48ef6 (#2228)  0 root files  skipped
  41d76c7 (#2225)  0 root files  skipped

So most merges to main never built at all. The second line never worked either:
path filters are repo-relative and take no leading slash, so '!/docs/*' matched
nothing - the docs exclusion it was written for was already being done, by
accident, by the '*' that excluded every subdirectory.

paths-ignore: 'docs/**' says what was meant: run for everything except a
docs-only change.

This matters more than it used to. release.yml takes its version from what a
green main run reports, so a main build that never runs means no version to tag
with - which is how this was noticed.