Fix Watch Mode

[CalebCourier]

Addresses #1201

Bug Description

Previously, operations on the SQLite DB used for watch mode (intended for local dev) were always run because they were fired from the legacy telemetry flow. This had the potential to cause DB lock errors if the user was using high rates of concurrency like noted in #1201.
Now, we avoid making calls to this SQLite DB unless watch mode is explicitly enabled via the --watch flag on the guardrails start command.

This isn't a perfect solution, because it forces the user to specify the "watch" functionality in two places:

1. in guardrails start --watch to enable collecting logs
2. in guardrails watch to tail the logs in a separate console tab

However there is not an easy way to communicate between these two commands since they currently exist as separate and unrelated processes.

This is technically a breaking change since it requires additional user interaction to obtain the same behaviour that previously was obtained without the addtional flag, but no one has used the guardrails watch command within the retention window of our metrics so it shouldn't matter.

Additionally, this entire "watch" functionality can, and probably should, just be handled by a logger in the same process as the guardrails-api. The current setup is a significant amount of overhead for something that essentially just prints out ValidatorLogs.

[CalebCourier]

Notebook passed on this branch: https://github.com/guardrails-ai/guardrails/actions/runs/12485660213