#278 add upper version bounds for fbe and judges

[VasilevNStas]

Both fbe and judges are pre-1.0 gems where minor version bumps may introduce breaking changes — API changes, CLI option changes, S-expression query syntax changes, and exit code changes.

The problem

# Before: no upper bound — could jump to 1.0 or higher
gem 'fbe', '>0'
gem 'judges', '>0'

If someone runs bundle update (accidentally or during Docker build without a lock file), versions could jump to a hypothetical 1.0 with breaking changes.

The fix

# After: constrained to 0.x series
gem 'fbe', '~>0'
gem 'judges', '~>0'

~>0 means >= 0 and < 1 — allows all 0.x releases but prevents jumping to 1.0.

Impact

Operation	Before	After
bundle install (with lock)	Exact version from lock	Same — lock wins
bundle update	Could jump to 1.0	Stays within 0.x
bundle install (without lock)	Latest version	Latest 0.x

The Gemfile.lock already pins exact versions, so production builds are unaffected. This change protects the next bundle update from surprise breakage.

Checklist

• bundle exec rubocop — 0 offences
• bundle exec rake — all tasks pass
• HoC ≤ 133

@yegor256 please review

[VasilevNStas]

@yegor256 — both fbe and judges are pre-1.0 gems where minor bumps may introduce breaking changes (CLI options, exit codes, S-expression syntax). The Gemfile had >0 with no upper bound. ~>0 constrains to the 0.x series, preventing bundle update from jumping to a hypothetical 1.0. Bonus: updates fbe 0.47→0.48 and judges 0.58→0.60 in the lockfile.