Modernize dependencies and fix Ruby 4.0 CI

[dduugg]

Summary

CI was failing because `minitest-5.16.3` requires `ruby < 4.0`, but the shared CI workflow now tests against Ruby 4.0.1. This follows the same process used in rubyatscale/packwerk-extensions#62.

Dependency updates:

• Update all outdated gems via `bundle update`: activesupport 7→8.1, rubocop 1.36→1.85, rubocop-sorbet 0.8→0.12, rubocop-ast 1.21→1.49, minitest 5.16→6.0, sorbet/tapioca, and many more
• Bump `required_ruby_version` in gemspec from `>= 2.7` to `>= 3.2` to match lowest CI Ruby version
• Remove bundler version constraint (`~> 2.2.16`) in gemspec — incompatible with bundler 4.0.7

Bug fixes required by updated gems:

• Fix `TypedPublicApis` spec: removed `let(:config) { RuboCop::Config.new }` override that replaced the `:config` shared context's properly-constructed config with a bare `RuboCop::Config.new`, which inherits `Enabled: false` from `config/default.yml`. In rubocop 1.85.1, `Registry#enabled?` strictly checks `== true` so the cop never ran.
• Fix `DocumentedPublicApis` cop: rubocop-ast 1.49.0 extended `non_public_modifier?` to also match `:private_class_method`. This caused `private_class_method def self.bar` to be treated as non-public, silently suppressing offenses for methods in `app/public`. Removed the `non_public?` guard — the cop is already restricted to `app/public` files where everything should be documented regardless of Ruby visibility.

Sorbet/Tapioca:

• Bump tapioca to 0.17.10 (requires spoom >= 1.7.9, which requires rbs >= 4.0.0.dev.4)
• Regenerate all tapioca RBI files for updated gem versions
• Add `sorbet/tapioca/config.yml` excluding `bundler`, `didyoumean`, and `msgpack` from tapioca gem RBI generation — these already have shims in sorbet's built-in RBI library
• Verified `srb tc` passes with no type errors

Linting:

• Add `rubocop-gusto` as a development dependency and plugin in `.rubocop.yml` (replaces `require: rubocop-sorbet`; rubocop-gusto transitively includes rubocop-sorbet)
• Add `inherit_mode`, `inherit_gem` config to `.rubocop.yml`
• Remove disabled Layout cops (`LineLength`, `MultilineMethodCallIndentation`, `FirstArgumentIndentation`, `ArgumentAlignment`) from `.rubocop.yml` and autocorrect resulting violations
• Autocorrect rubocop offenses throughout; regenerate `.rubocop_todo.yml` for remaining violations

Rake task:

• Refactor `tasks/cop_documentation.rake`: replace `define_method` calls (flagged by `Gusto/NoMetaprogramming`) with a `CopDocumentation` module using `self.` methods; extend `Rake::DSL` so `sh` is available without passing the task context as a parameter

Housekeeping:

• Remove `.DS_Store` from git tracking (`.DS_Store` is a per-user concern and belongs in each developer's global gitignore, not the project's `.gitignore`)
• Remove `spec/rubocop/packs_spec.rb` — the file contained only a `before` hook with no examples; `rubocop-rspec` correctly identified it as an empty example group
• Regenerate binstubs with current bundler (`bundle binstubs rubocop tapioca --force`)

Fixes https://github.com/rubyatscale/rubocop-packs/actions/runs/22733673075/job/65929220506

🤖 Generated with Claude Code

[dduugg]

The parent class Style::DocumentationMethod has this guard to skip Ruby-private/protected methods when RequireForNonPublicMethods is not configured — it makes sense globally, where you may not want to enforce documentation on every private method across an entire codebase.

This cop is already restricted to app/public files, so the guard is semantically wrong here: a method like private_class_method def self.bar is Ruby-private but pack-public — it's part of the pack's public API surface and should always be documented.

The line was harmless until rubocop-ast 1.49.0 extended non_public_modifier? to also match :private_class_method (previously only :private and :protected matched). After that change, non_public?(node) returned true for private_class_method def self.bar, causing the guard to silently suppress offenses for methods in app/public.

[dduugg]

spec/rubocop/cop/packs/typed_public_apis_spec.rb — removal of let(:config) { RuboCop::Config.new }

This override replaced the config provided by RuboCop's :config shared context with a bare RuboCop::Config.new. The shared context sets Enabled: true for the cop under test, but RuboCop::Config.new inherits Enabled: false from config/default.yml (where all cops in this gem default to disabled so they must be explicitly opted into).

In rubocop 1.36.0 this was harmless — the cop ran regardless. In rubocop 1.85.1, Registry#enabled? strictly checks cfg.fetch('Enabled') == true and excludes the cop from the run entirely. The result was that the test expecting an offense passed vacuously (no cop ran, no offense reported, expect_no_offenses trivially satisfied) while the test expecting an offense silently failed.

Removing the override lets the :config shared context supply a properly-constructed config with Enabled: true.