Add opt-in occupancy event publishing

[darvell]

This PR adds a new opt-in feature that publishes occupancy state changes to the Particle cloud, enabling real-time awareness of space usage via webhooks/streams.

New Features

• Toggle_Occupancy_Events console function to enable/disable the feature (opt-in, default: disabled)
• Publishes 'Occupancy Changed' events when occupancy state changes:
  • Occupied: State 0→1 (initial detection) and State 1→2 (confirmed occupancy)
  • Not occupied: State 2→0 and State 3→0 (door opened, session ended)

Event Payload

{
  "occupied": "true",
  "state": "2",
  "door_status": "0x08",
  "INS_val": "15.300000",
  "timestamp": "123456789"
}

Data Usage

• Only publishes on state changes (not periodic)
• ~80 bytes per event
• Typical usage: 2-4 events per bathroom session
• Minimal impact on data plan

Usage

1. Call 'Toggle_Occupancy_Events' with "1" to enable (persists to EEPROM)
2. Call with "0" to disable
3. Call with "e" to check current status

Files Changed

• 'flashAddresses.h' - Added EEPROM address for occupancy events flag
• 'debugFlags.h/cpp' - Added occupancy events flag and timestamp
• 'consoleFunctions.h/cpp' - Added Toggle_Occupancy_Events console function
• 'stateMachine.h/cpp' - Added publishOccupancyEvent() and calls at state transitions
• 'BraveSensorProductionFirmware.ino' - Bumped version to 12028

Safety Considerations

• Feature is opt-in and disabled by default
• Setting persists to EEPROM (survives reboots)
• Rate limited to 1 publish per 500ms to prevent data overage
• No impact on existing alert functionality

Testing

• Test Toggle_Occupancy_Events console function
• Verify events publish on state transitions
• Verify setting persists after reboot
• Verify no events published when disabled
• Verify rate limiting works

[Phlashy]

Can we double-check the data impact of this? Our Particle thresholds are quite restrictive and have super annoying burst pricing (?) where we end up on a more expensive tier forever if we burst through x MBs in a month. I can't recall what they are or where we're at, but I know that about 18 months ago we ended up bursting through it because we were accidentally leaving the dev environment on over the weekend which somehow blew through our entire budget. (Hence the Slack auto-reminder every week to turn it off.)

Johnny knows all the details.

[Phlashy]

ps. Otherwise I love it!!!

[darvell]

Under the current plan, you could do 2,620/day per sensor.

[Phlashy]

I think we need to look at our current usage and go from there. My question is about the total amount of data we're using, so we need to know our current baseline and see what capacity we have.

Also, I don't fully understand how the capacity we have works but we've been burned before and they were willing to give us a free pass for that and ratchet us back down to the lower pricing tier. I don't think they'll do that again.