fix(gnomon-export): add missing JSCalendar property mappings and warnings API

[eikopf]

Summary

• Fixes gnomon-export: JSCalendar export missing many standardized property mappings #50: Adds ~15 new standardised JSCalendar property mappings per event/task type (created, updated, sequence, method, recurrenceId, recurrenceRules, excludedRecurrenceRules, locations, virtualLocations, links, relatedTo, participants, replyTo, requestStatus) so they emit proper JSCalendar model types instead of falling through to vendor properties.
• Fixes gnomon-export: asymmetric warning APIs between iCal and JSCal exporters #54: Adds warnings: &mut Vec<String> parameter to emit_jscalendar (matching emit_icalendar's existing API) and emits warnings for unrecognised non-vendor fields.
• Updates the spec (spec/gnomon.md) with expanded JSCalendar import/export mapping tables and a new r[model.export.jscalendar.unknown] requirement.

Changes

crates/gnomon-export/src/jscal.rs

• emit_jscalendar and internal builders now thread warnings: &mut Vec<String>
• New builder functions: record_to_rrule, build_locations, build_virtual_locations, build_links, build_related_to, build_event_participants, build_task_participants, build_reply_to, build_request_status, parse_status_code
• collect_vendor_properties now warns about non-vendor fields (those not containing :)
• 12 new tests covering all new property mappings and warning behaviour

crates/gnomon-export/Cargo.toml

• Added rfc5545-types = "0.1" dependency (for DateTimeOrDate used in rrule termination)

spec/gnomon.md

• Bumped r[model.import.jscalendar.event] and r[model.import.jscalendar.task] to +2 with 15 new property rows each
• Bumped r[model.export.jscalendar.event] and r[model.export.jscalendar.task] to +2 with expanded descriptions
• Added r[model.export.jscalendar.unknown] requiring warnings for unrecognised non-vendor fields

Test plan

• cargo test --workspace passes (all 37 gnomon-export tests pass, including 12 new ones)
• cargo check --workspace passes with no warnings
• Manual verification: run gnomon export --format jscalendar on a file with iCal-imported records containing locations, rrules, participants, etc.

🤖 Generated with Claude Code

[eikopf]

The JSCalendar export (from a source containing iCalendar data) currently fails for several reasons, most notably because the DTSTART property on events is not being converted properly and because the root VCALENDAR objects do not contain UIDs.

The draft RFC for converting between iCalendar and JSCalendar describes a scheme to be used for generating stable UUIDs for such cases, and in general we should give this document more weight in our implementation.

[eikopf]

We're abandoning this in favour of a more principled approach (see #90).