OpenDroneID: use the UTC epoch for the 2019 timestamp

[Abtektas]

Fixes #1282.

The OpenDroneID module sends timestamp in OPEN_DRONE_ID_SYSTEM and OPEN_DRONE_ID_SYSTEM_UPDATE as seconds since 00:00:00 on 2019-01-01. The constant it subtracts for that date is wrong:

	value	date
in the code	1546261200	2018-12-31 13:00:00 UTC
correct	1546300800	2019-01-01 00:00:00 UTC

The difference is 39600 s, so the timestamps were 11 hours ahead. (The old value is midnight on 2019-01-01 in UTC+11.)

This PR changes the constant and adds tests/test_opendroneid.py, which fixes the clock at 90 s after 2019-01-01 00:00:00 UTC and expects timestamp_2019() to return 90.

Testing

macOS (arm64), Python 3.14.7, pytest 9.1.1, pymavlink 2.4.49:

• tests/test_opendroneid.py fails without the change and passes with it.
• tests/test_rline.py and tests/test_sysid32.py still pass (18 tests together with the new one).
• scripts/run_flake8.py MAVProxy reports nothing, and flake8 is clean on the new test.

I did not run the rest of the test suite (it needs OpenCV, matplotlib and wx, which I did not install), and I have no Remote ID hardware, so this is not tested against a transmitter.

This contribution was AI-assisted (Claude Code): it checked the issue against current master, wrote the change and the test and ran the checks above. I have not reviewed the code myself.

🤖 Generated with Claude Code

[AP-Review]

Automated review note — AI-generated (Claude), validated against the live diff. Please sanity-check before acting.
Verdict: ACCEPT

Reviewed at head ea4db2d917.
Full report: https://firmware.ardupilot.org/Tools/APReview/DevCallReviews/PRReviews/ardupilot/mavproxy/1767/1.html#prMAVProxy-1767

Looks good. 1546300800 is 2019-01-01 00:00:00 UTC, the epoch that the MAVLink OPEN_DRONE_ID_SYSTEM and SYSTEM_UPDATE timestamp fields are defined against (https://github.com/ArduPilot/MAVProxy/pull/1767/files#diff-c9d9843738871431245a9921898e2aa4ea08d8b989e0f669cfbf1b66958235a9R169). The old value was midnight at UTC+11, so these timestamps were 11 hours ahead. Both messages get their timestamp from this one helper, so both are fixed. The new test (https://github.com/ArduPilot/MAVProxy/pull/1767/files#diff-158b7ac65d84fa9e7a148d5c58b635413371cdddd57ce1ebb6387817bfa71f29R11) passes at ea4db2d and fails against the base with 39690 != 90, so it guards this regression. No issues found. A live Remote ID receiver and the full test suite on other Python/pymavlink versions were not exercised.