The version check used the PCRE escape \d in an egrep pattern:

  REGEX_VERSION='^\d+\.\d+\.\d+$'
  MATCHES=$(echo "$1" | egrep $REGEX_VERSION | wc -l)

egrep uses POSIX Extended Regular Expressions, which do not support \d.
The pattern therefore matched nothing, every input was treated as
invalid, and the script always exited with:

  Version "X.Y.Z" must be N.N.N

This caused the 'Run start_release.sh and open a release PR' job to fail
with exit code 1 even though VERSION=1.3.0 had already passed the
workflow's own pre-check (which uses bash regex ^[0-9]+\.[0-9]+\.[0-9]+$).

Replace \d with [0-9] so the regex actually matches N.N.N, and quote the
variable expansion in egrep for safety.

… crate

CI's 'no duplicate aws-lc native crate' check failed on the default
build with:

    aws-lc-sys v0.41.0
    └── aws-db-esdk (direct dependency)

    aws-lc-sys v0.42.0
    └── aws-lc-rs v1.17.1
        └── aws-db-esdk (transitive via aws-lc-rs/aws-sdk-*)

Our Cargo.toml pinned the direct optional dep at aws-lc-sys = "0.41",
while aws-lc-rs 1.17.1 (which we depend on, and which the AWS SDK
crates pull in transitively) resolves aws-lc-sys 0.42. Cargo cannot
unify across a semver-major boundary, so two copies of aws-lc-sys
compile in the same build.

Beyond the ~2x native C build cost, this is also a correctness/safety
concern: the SDK's raw FFI path (aws_lc_sys_impl::*) binds to the
version WE declare, while aws-lc-rs binds to the version it pulls in,
so the raw path can drift onto a stale/vulnerable AWS-LC independently
of aws-lc-rs.

Bump the direct dep to aws-lc-sys = "0.42" so it unifies with the
version aws-lc-rs resolves to. aws-lc-fips-sys is unchanged; the fips
build was not flagged by the duplicate check.