Introduces a custom `bin/main.dart` entrypoint to shift the application from a lazy-loading to an eager-loading model.
This new entrypoint ensures that all application dependencies are initialized upfront before the Dart Frog server starts. If any initialization step fails, the server process will exit immediately, providing a robust "fail-fast" startup sequence and eliminating race conditions.

Removes all lazy-loading and race-condition handling logic from the `AppDependencies` class. This includes the `_isInitialized` flag, error caching fields, and the `try-catch` block within the `init` method.
With the new eager-loading entrypoint, initialization is guaranteed to happen once at startup, making this complex state management logic redundant. The class is now a simpler, more direct dependency initializer.

Updates the root middleware to remove the `AppDependencies.instance.init()` call.
Since initialization is now handled eagerly at application startup by the new custom entrypoint, the middleware's responsibility is simplified to only providing the already-initialized dependencies into the request context.

Adds the `executables` section to `pubspec.yaml` to define the new `bin/main.dart` script as a named executable.
This allows the server to be started with `dart run :main`, which is the new standard for running the application with the eager-loading strategy.

Updates the README.md to include a new section under "Architecture & Infrastructure" that highlights the "Eager Loading & Fail-Fast Startup" pattern.
This change accurately reflects the recent architectural overhaul, explaining the benefits of initializing all dependencies before the server starts, which enhances robustness and stability.

Updates the changelog to include the recent architectural shift to an eager-loading startup model. This is marked as a breaking change (`!`) because it alters the command used to run the server.

Relocates the global logger configuration from the root middleware (`routes/_middleware.dart`) to the new eager-loading entrypoint (`bin/main.dart`).
This is an architectural improvement that ensures the logger is configured exactly once when the application process starts, rather than within a middleware that could be re-instantiated. It makes the startup sequence more robust and simplifies the root middleware's responsibilities.

Removes the `await` from the `server.main()` call in the custom entrypoint, as the function returns `void`. Also removes redundant `// ignore: avoid_print` comments that were duplicated by a file-level ignore, resolving linter warnings.

- Integrate shelf_hotreload package for hot reload capability
- Wrap server startup logic with withHotreload function
- Preserve eager initialization of dependencies
- Maintain "fail-fast" approach for production readiness
- Update server startup to use createServer function from Dart Frog

...patibility
- Update CHANGELOG.md to reflect the new hot reload compatibility of eager loading
- Enhance the description to include Dart Frog's hot reload feature

Removes the `reset()` static method and makes the `_instance` field `final` again. This logic was introduced to support hot reloading, which has since been removed from the custom entrypoint.
This change cleans up the `AppDependencies` class, removing dead code and preventing confusion about the server's startup behavior.

@gemini-code-assist gemini-code-assist bot left a comment

Implements two key production-readiness features based on code review:
1. **Graceful Shutdown:** The `main.dart` entrypoint now listens for `SIGINT` and `SIGTERM` signals. Upon receiving a signal, it closes the HTTP server to stop accepting new connections, disposes of all application dependencies (like the database connection), and then exits cleanly. This prevents resource leaks.
2. **Atomic Logging:** The logger configuration in `main.dart` has been refactored to use a `StringBuffer` and a single `stdout.write()` call. This ensures that multi-line log entries are written to the console atomically, preventing interleaved output and improving log readability.
A defensive check has also been added to `AppDependencies.dispose` to ensure it can be called safely even if initialization failed.

- Add a platform check before listening for SIGTERM signal
- Prevent errors on Windows platforms that don't support SIGTERM

@gemini-code-assist gemini-code-assist bot left a comment

Fixes a type error where `buildRootHandler()` was being inferred as `dynamic` instead of `Handler`. The fix explicitly casts the result to `Handler` before passing it to the `serve` function, resolving the static analysis error and ensuring type safety.

Replaces the asynchronous `log.severe` call in the main catch block with a direct, synchronous write to `stderr`, followed by `stderr.flush()`.
This fixes a race condition where the process could exit before the logger had a chance to write the fatal error message, ensuring that critical startup failure information is never lost.