Add sentry integration

[MaxAlex]

Adds Sentry integration to Odin. In theory, this just requires adding a sentry_sdk.init() call and everything will just work. There are a few complications:

• Sentry initialization modifies exception handling infrastructure in the current Python process, so this doesn't carry over into subprocesses (such as those used to run OdinJob via multiprocessing.) There's a couple ways to address this, of which the simplest is to just call have OdinJob call init() for every subprocess.
• Sentry ingests errors in two ways; either by parsing error output from logs, or by explicit calls to functions like sentry_sdk.capture_exception. The problem with the former method is that Sentry's error parsing doesn't seem to be very good, and doesn't seem to like our current logging infrastructure, so a single exception will wind up smeared into a dozen or so Sentry incident reports. This would be difficult to fix without significantly changing how logs appear in Splunk, so to keep things consistent I've put in a try-except that calls sentry_sdk.capture_exception in job.py, and disabled log-parsing-based Sentry reports there. Importantly, errors outside of an OdinJob will still be reported from logs.
• cubic_archive.py would previously report missing snapshot data for a table by throwing an exception. Since some tables aren't being sent over in dev this has been constantly emitting alerts, which we've been ignoring. It would also be a constantly-updated Sentry report, so this PR suppresses that 'error.'

[ealexa05]

Logging for Sentry looks sound, and other functionality looks to be preserved. Non-blocking note, since we are syncing requirements.txt/requirements-dev.txt, we should either keep those files up to date or remove them

[MaxAlex]

Logging for Sentry looks sound, and other functionality looks to be preserved. Non-blocking note, since we are syncing requirements.txt/requirements-dev.txt, we should either keep those files up to date or remove them

I made new requirements.txt/requirements-dev.txt files via pip-compile, which produced large diffs (I guess the original files were made some other way?) even though the version sets, according to log_installed_packages reporting on dev, are mostly the same:

>>> newer-older
{'sentry-sdk=2.68.1', 'deltalake=1.6.3', 'arro3-core=0.8.2', 'types-PyYAML=6.0.12.20260815', 'wrapt=2.4.0'}
>>> older-newer
{'deltalake=1.6.2', 'arro3-core=0.8.1', 'types-PyYAML=6.0.12.20260724', 'wrapt=2.3.0'}