v0.2.2

fix(provider): discover jobs in ready(), which is what runs after the preloads

The previous move put discovery in start() on the belief that preloads run
between boot and start. They do not. Upstream's warm-up is
providers.start() -> the starting hooks -> the preloads, so start() is
still BEFORE them -- a job reaching for a service a preload registers found
nothing, exactly as it did from boot.

ready() is the phase that runs after all of it, and it is also the phase an
inspection does not run: ream inspect and a codegen pass no longer import
every job in the application.

Coverage: the boot/start split and the branches that reject a file left the
branch floor short, so the paths are covered rather than the floor lowered --
a nested directory (which is what make:job emails/X writes), a .d.ts beside
a job, and a module that is not an object at all.

fix: discover jobs in start(), and refuse to come up with none

Discovery IMPORTS application modules and it ran in boot(), before preloads. A
job reaching for a container service -- the ordinary way to write one -- then
waited on a boot that was waiting on its own import. It moves to start(),
which is what the phase is for: by then the application is assembled and a job
may depend on it. Setting the make:job directory stays in boot, being
bookkeeping.

The "no handlers" guard only fired when every file failed to LOAD. A file that
imported cleanly and exported the wrong thing was skipped in silence -- the
shape a rename or a forgotten export default takes -- so a directory of files
that all compiled and none of which held a Job produced an empty discovery and a
worker that accepted jobs and processed none.

The reason no longer matters: scanning files and finding no Job is a failure.
Each skipped file also says what it exported instead, so the fix is the next
thing you read rather than something to go looking for.

---

Changes since v0.2.1.