fix(emitter): never emit a null timezone; reject one in validate

[scottbrumley]

The bug

The platform rejects a null timezone outright:

POST /public_api/v1/correlations/insert
HTTP 400 "Failed to create correlation rule due to: Invalid timezone"

The pack still installs and the installer reports success, so the rule simply
never exists on the tenant and nothing surfaces why.

Why it is everywhere

Only 3 of 16 vendor schemas declare timezone. For the other 13 the emitter
passed the missing value straight through as null — so a schema that merely
omitted the key produced an uninstallable rule. 15 of the 17 correlation
rules in this repo ship timezone: null.

This is not a regression

generate_vendor_content.py had not changed since 4 Aug. The null passthrough
has been there the whole time.

#959  soc-crowdstrike-falcon born     timezone: null
#961  soc-crowdstrike-falcon FIXED    null -> UTC
#962  soc-crowdstrike-idp   born      timezone: null   <- cloned pre-fix pattern
#963  soc-crowdstrike-saas  born      timezone: null

IDP and SaaS have never worked since their first commit. The three vendor packs
created on 14 Sep (microsoft-purview-dlp, nozomi-guardian,
spycloud-enterprise-protection) were born the same way.

The fix

• emitter — a missing timezone defaults to UTC instead of null.
  Schemas may still set it explicitly (pan-cie uses America/New_York).
• validate_mapping — an explicit null/empty timezone is now a hard error
  carrying the platform's own rejection message.

Verified on deathstar

• Emitted the sentinel-one rule with the fix and inserted it → HTTP 200,
  rule created (id 266, deleted after). Before the fix that pack emitted null.
• Negative test: reverting the IDP schema to null now fails validation.
• All 16 vendor schemas validate.
• Roundtrip across every vendor pack: timezone: null -> UTC on the 12
  affected packs, no drift on the 4 already correct.

Not done here

The 12 affected packs still ship the old null in their committed rule YAML.
They need a re-emit and release each — deliberately out of scope for a tooling
change.

Labels: version:patch

[scottbrumley]

Closing unmerged. The premise in this PR description -- that a null timezone makes a correlation rule uninstallable -- is contradicted by observation: packs shipping timezone: null have installed and their rules have worked on tenants. The HTTP 400 almost certainly comes from correlations/insert, the direct REST path, not from the pack bundle installer that a pack install actually uses.

If that holds, this fixes a defect that only bites API-driven rule creation (i.e. our own test tooling), and the "15 of 17 rules are uninstallable" framing here is wrong. Reopen if the insert path turns out to matter.