Bumps [step-security/harden-runner](https://github.com/step-security/harden-runner) from 2.13.3 to 2.14.0.
- [Release notes](https://github.com/step-security/harden-runner/releases)
- [Commits](step-security/harden-runner@df199fb...20cf305)

---
updated-dependencies:
- dependency-name: step-security/harden-runner
  dependency-version: 2.14.0
  dependency-type: direct:production
  update-type: version-update:semver-minor
...

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

When `SequenceSet#max(n)` is called with `n > cardinality`, it _should_
return a duplicate of the whole set.  But, `#max(n)` is implemented
using `#slice(-n..)`, and (copying the behavior of `Array`), when a
slicing starts from an out-of-range index, it returns `nil`.

It was using `-[count, size].min` to keep the index from going
out-of-range.  Prior to #564, `#size` was the same as `#count`, so it
would give incorrect results when the set contains an endless range.
After #564, this gives incorrect results when the ordered list contains
duplicates.

This change should also give a small performance boost, because it
bypasses the complexity of `#slice(range)` and just calls `#dup` (or
returns `self` when the set is frozen).

This issue was one of the motivations for #563 (and #564), but then I
forgot about the bug, so it wasn't fixed in time for 0.6.0!