Persist recorded sensor values with collision handling

[BelhsanHmida]

Add the backend service and endpoint needed to validate and persist values recorded on a sensor graph, including values produced by recurrence expansion.

Acceptance criteria

• Operate only on the sensor identified by the sensor page or endpoint.
• Require the appropriate permission to create sensor data.
• Validate event starts, values, resolution, timezone, and belief time.
• Use the selected belief time, defaulting to the current time when none is supplied.
• Allow values for the same event start when their belief times differ.
• When an exact event-start and belief-time collision exists, preserve the existing belief.
• Return a summary of values created, skipped because of collisions, and rejected.
• Persist the batch atomically so partial failures do not leave an incomplete recording.
• Reuse the recurrence-expansion function rather than implementing DST behavior in the route.

Tests

• Successful single-value and batch recording.
• Permission failure.
• Same event start with a different belief time.
• Exact collision where the existing belief wins.
• Validation failure rolls back the full batch.

Out of scope

• Graph recording controls.
• Recurrence stored as schema rather than concrete beliefs.

[Flix6x]

I'd like to see a proposed implementation plan for this issue before starting development.

backend service and endpoint needed to validate and persist values recorded on a sensor graph

Specifically, it isn't evident to me how the endpoint is supposed to differ from the endpoint we already have for POSTing sensor data.

Also, a terminology remark: this issue uses the term "recorded sensor values" to mean (correct me if I'm wrong) drawn values captured from a UI graph. There are many places in the existing codebase and docs where the same phrase would be understood to mean persisted in the db. This is what makes "Persist recorded sensor values" in the issue title feel like a semantic contradiction.