automod consuming ozone events (#698)

This has automod consume events from Ozone and feed them in to the rules
engine, similar to firehose events. It uses the queryEvents endpoint,
polling every 5 seconds. This is all optional; if an ozone admin client
isn't configured, it doesn't happen.

- some types of ozone events on an account subject result in account
metadata getting flushed. this ensures that, eg, manually-added labels
or takedowns end up in automod-visible cached account metadata
- harassment protection rule is updated to look in private tag state
from ozone, not just a deployed config JSON file. this was actually more
complex than I would thought, and results in additional account metadata
fetches, but those are all cached (with cache purging!) so should be
fine
- private/admin account metadata queries go to ozone, not PDS/entryway,
by default. this could increase API load on ozone a bunch; we might need
to optimize that code path
- ignores events caused by mod service automation (eg, automod itself)
- does not currently have any tests 😞 but I tested a fair
bit in staging. would go slow and careful with any prod deploy

Some follow-ups for future work (recording these from my local dev
notes):

- automod "flags" and ozone "tags" are kind of duplicate. I originally
thought these would have automod "flags" show up as "tags" in Ozone. but
should think that through again (maybe flags are useful outside ozone?)
and how to refactor things if they should be the same concept
- entirely rip out PDS/entryway private metadata queries, once we are
confident ozone is sufficient
- get publicly-available account creation timestamp working
consistently. this could include tweaks to appview+ozone endpoints, and
possibly even going to PLC directory for more authoritative timestamps
- should probably refactor account metadata struct in to more clearly
distinct "bsky-specific" (from appview), "ozone-specific" (private
metadata), and public account/identity info
- should probably handle account metadata more consistently across
ozone, automod, and other systems. related to the `#identity` and
`#account` refactors, we now have a concept of account status at various
pieces of infrastructure (active, takendown, deactivated, suspended,
deleted), and should represent that cleanly
- `OzoneEventContext` currently extends `AccountContext`, with the
subject account as "the account". currently all ozone events have an
associated subject account, while record is optional. we might end up
with events that don't have a meaningful subject account? or want to
have better ergonomics with a record-variant of ozone event context?
those are more complex, feels like things are fine for now
- would like to refactor the "consumption" code (firehose and ozone
events) out of the `cmd/hepa/` folder and in to `automod/`

Update: created a separate issue to track these refactors:
#700