.rubocop.yml pins TargetRubyVersion to 2.6.0 while CI runs Ruby 3.3

.rubocop.yml sets TargetRubyVersion: 2.6.0 on line 10, while .github/workflows/rake.yml pins the CI matrix to ruby: [3.3] and Gemfile.lock ends with BUNDLED WITH 2.5.16 shipped on Ruby >= 3. RuboCop therefore lints every file as if the source had to remain compatible with Ruby 2.6, so it skips cops that only activate on 3.0+ (pattern matching, endless methods, hash shorthand, Integer#ceildiv, etc.) and may keep flagging idioms that 3.x renders moot.

The mismatch silently weakens the static-analysis gate: the CI pipeline never runs a 2.6 interpreter, no gem in Gemfile.lock still supports 2.6 (e.g. csv 3.3.5, date 3.5.1, bigdecimal 4.1.2 all require Ruby >= 3.0), and Ruby 2.6 has been end-of-life since March 2022. Either the project actually intends to support Ruby 2.6 — in which case the CI matrix needs a 2.6 row and the Gemfile pins need to be relaxed — or, more likely, the target version is stale.

Bumping TargetRubyVersion in .rubocop.yml to 3.3 (matching the CI matrix) is a one-line change that re-aligns the linter with the runtime and unlocks the 3.x cop set.