chore: bump rubocop to ~> 1.86 and rubocop-rspec to ~> 3.9

[erimicel]

Summary

• rubocop: 1.72.2 (pinned exact) → ~> 1.86
• rubocop-rspec: ~> 3.6 → ~> 3.9

Loosens the rubocop constraint to a pessimistic operator so future patch/minor bumps don't require another Gemfile change.

What broke (and why it didn't)

The newer cop set surfaced 10 offences. They split into three groups:

1. Style/HashAsLastArrayItem + Layout/SpaceInsideHashLiteralBraces in collection_spec.rb (1 real, autocorrected)

Pre-existing array-of-hash literal that was missing braces. bundle exec rubocop -a fixed it cleanly:

       update_schema = {
         'fields' => [
-          'name' => 'field', 'drop' => true
+          { 'name' => 'field', 'drop' => true }
         ]
       }

2. RSpec/Output in spec/spec_helper.rb × 8 (cop misfiring)

The new cop flags puts/print in spec files because it expects output assertions to be wrapped in expect { }.to output(...).to_stdout blocks. But spec/spec_helper.rb here is integration infrastructure — ensure_typesense_running boots Typesense via docker-compose and reports startup progress to the operator. Those are not assertions. Auto-correct would either delete or break the progress messages.

Resolved by adding a scoped exclusion in .rubocop.yml:

RSpec/Output:
  Exclude:
    - spec/spec_helper.rb

3. Naming/PredicateMethod in spec/spec_helper.rb × 1 (cop misfiring)

ensure_typesense_running returns a boolean (whether this test run started the Typesense container, used by the after(:suite) hook to decide whether to tear it down). But the method has heavy side effects — it pulls a docker image, starts a container, polls a health endpoint, and writes to stdout. Renaming to ensure_typesense_running? to satisfy the predicate-naming convention would actively mislead callers about its cost. Same scoped exclusion treatment.

Verification

• bundle exec rubocop — 97 files inspected, 0 offences.

PR Checklist

• I have read and signed the Contributor License Agreement.