`i18n` scope incompatible with `exists?`

[swatosh]

Context

I'm trying to upgrade to Spree 4.6, which pulls in mobility

Expected Behavior

The i18n scope should "pass through" the arguments to exists?

Actual Behavior

The i18n scope does not "pass through" the arguments to exists?

I think the SQL logs from this irb session tell the story (and how I concluded it was the i18n scope)

irb(main):119:0> Spree::VERSION
=> "4.6.0"
irb(main):120:0> Spree::Product.exists?(name: 'name')
  Spree::Product Exists? (0.4ms)  SELECT 1 AS one FROM "spree_products" WHERE "spree_products"."deleted_at" IS NULL LIMIT $1  [["LIMIT", 1]]
=> true
irb(main):121:0> Spree::Product.unscoped.exists?(name: 'name')
  Spree::Product Exists? (0.4ms)  SELECT 1 AS one FROM "spree_products" WHERE "spree_products"."name" = $1 LIMIT $2  [["name", "name"], ["LIMIT", 1]]
=> false
irb(main):122:0> puts Spree::Product.default_scopes.map { |ds| ds.scope.source }
      default_scope { i18n }
        default_scope { paranoia_scope }
=> nil
irb(main):123:0> Spree::Product.unscoped.i18n.paranoia_scope.exists?(name: 'name')
  Spree::Product Exists? (0.4ms)  SELECT 1 AS one FROM "spree_products" WHERE "spree_products"."deleted_at" IS NULL LIMIT $1  [["LIMIT", 1]]
=> true
irb(main):124:0> Spree::Product.unscoped.i18n.exists?(name: 'name')
  Spree::Product Exists? (0.5ms)  SELECT 1 AS one FROM "spree_products" LIMIT $1  [["LIMIT", 1]]
=> true
irb(main):125:0> Spree::Product.unscoped.paranoia_scope.exists?(name: 'name')
  Spree::Product Exists? (0.4ms)  SELECT 1 AS one FROM "spree_products" WHERE "spree_products"."deleted_at" IS NULL AND "spree_products"."name" = $1 LIMIT $2  [["name", "name"], ["LIMIT", 1]]
=> false
irb(main):126:0> Spree::Product.method(:i18n).source_location.join(':')
=> "/Users/joe/.rbenv/versions/3.0.5/lib/ruby/gems/3.0.0/gems/mobility-1.2.9/lib/mobility/plugins/active_record/query.rb:32"
irb(main):127:0> Mobility::VERSION::STRING
irb(main):128:0*
=> "1.2.9"
irb(main):129:0>

Possible Fix

Not sure how to fix it, but could be related to #621 as it talks about another instance of the wrong query being built?