using variable inside block of type check leads to "stack level too deep (SystemStackError)"

Describe the Bug

I've written a catch_error with followup type check to =~ Error exactly like written in the bolt docs "catching errors in plans". If I use the variable inside the block of the type checking the plan crashes with a "stack level too deep (SystemStackError)". The idea is to nest the original error for deeper debugging cases.

Expected Behavior

Plan doesn't crash and returns the defined custom error defined in the fail_plan line and is able to include the original error within the new error details hash.

Steps to Reproduce

plan somemodule::test() {
  $t = Target.new('some-target')
  $group = 'some-nonexistent-group'
  $add_or_error = catch_errors(['bolt.inventory/validation-error']) || { $t.add_to_group($group) }
  out::message("add_or_error: ${add_or_error}")
  if $add_or_error =~ Error {
    fail_plan('group not found in inventory', 'inventory/not-found', { 'group' => $group, 'error' => $add_or_error }) # this fails
    # fail_plan('group not found in inventory', 'inventory/not-found', { 'group' => $group }) # this works but we are missing the original error
  }

  return 'it did it!'
}

Environment

• Version 4.0.0 (also happens in 3.30.0)
• Platform Devuan daedalus (debian bookworm)

Additional Context

$ bolt plan run somemodule::test --format json
add_or_error: Error({'msg' => 'Group some-nonexistent-group does not exist in inventory', 'kind' => 'bolt.inventory/validation-error', 'details' => {'path' => []}})
/opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/concurrent-ruby-1.2.3/lib/concurrent-ruby/concurrent/atomic/thread_local_var.rb:71:in `value': stack level too deep (SystemStackError)
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet/context.rb:56:in `lookup'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet.rb:284:in `lookup'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet/pops/loaders.rb:120:in `implementation_registry'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet/pops/types/type_calculator.rb:536:in `infer_Object'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet/pops/visitor.rb:94:in `visit_this_0'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet/pops/types/type_calculator.rb:270:in `infer'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet/pops/types/type_calculator.rb:289:in `infer_set'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/puppet-8.10.0/lib/puppet/pops/types/type_calculator.rb:160:in `infer_set'
         ... 8080 levels...
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/bolt-4.0.0/lib/bolt/cli.rb:394:in `execute'
        from /opt/puppetlabs/bolt/lib/ruby/gems/3.2.0/gems/bolt-4.0.0/exe/bolt:11:in `<top (required)>'
        from /opt/puppetlabs/bolt/bin/bolt:25:in `load'
        from /opt/puppetlabs/bolt/bin/bolt:25:in `<main>'

Reproduce the plan from the issue, then trace the recursion through Puppet's type calculator, especially puppet/pops/types/type_calculator.rb and the infer_set path shown in the stack trace. Confirm the fix by rerunning the example through the bolt CLI and verifying that the plan returns the custom error with the original error in its details hash without a SystemStackError.