Let bin/jobs check validate another env's config section without a database

[wintan1418]

Fixes #780

Follows the analysis in #780 (thanks @kylekeesling for the detailed report — this implements both fixes you outlined).

1. --env option for bin/jobs check

check always read the config files through the current Rails env, so a CI run in the test env couldn't inspect the production: section of config/recurring.yml — and config_from's whole-file fallback made it worse: with no test: key it treated production as a task with no :schedule, dropped it, and reported an empty configuration valid.

$ RAILS_ENV=test bin/jobs check --env production --recurring_schedule_file config/recurring.yml
Solid Queue configuration is invalid:
  Invalid recurring tasks:
  - my_task: Schedule is not a supported recurring schedule
$ echo $?
1

The option only exists on check — start keeps running strictly under the current env.

2. check no longer requires a database

Configuration used to instantiate RecurringTask Active Record models just to list the configured processes, which needs the solid_queue_recurring_tasks schema and blew up with a raw StatementInvalid backtrace in environments with no queue database. Now it passes the scheduler raw [ key, options ] pairs — RecurringSchedule already wraps whatever it receives via RecurringTask.wrap at boot, in the running process where a database is guaranteed — so process listing is database-free.

Task-level validation (schedule syntax, job class existence) still requires the schema to build the models. When there's no usable connection, check now degrades to an explicit warning instead of crashing, mirroring the rescue the pool-size warning already had, and still validates everything else:

$ RAILS_ENV=test bin/jobs check --env production   # no queue database configured for test
Warning: recurring tasks couldn't be validated because there's no usable database connection. Run `bin/jobs check` with the Solid Queue database reachable to validate them.
Solid Queue configuration is valid.

Making task-level validation itself database-free would mean decoupling RecurringTask's validations from Active Record; that felt like a separate discussion, and the warning keeps check honest about what it did and didn't verify in the meantime.

Tests

• --env targeting validates the production:-only recurring fixture from the test env, including instantiating the scheduler from the raw definitions.
• With RecurringTask.from_configuration raising StatementInvalid (no schema), the scheduler is still detected from the raw configuration, check stays valid, and the warning is reported.