docs+test: thread-safety contract for EquipmentDataModel

INTEGRATION.md §3 used to show a sensor-poll thread calling
model->svids.set_value() directly while the io_context thread reads
the same SVID for an inbound S1F3.  That's a data race — there are
zero locks anywhere in EquipmentDataModel and there's no intention
to add them.  The library is single-threaded by design; the doc was
just inviting trouble.

This commit makes the actual contract explicit:

- INTEGRATION.md §3: thread-safety callout box.  All access must run
  on the io_context that drives the HSMS connection.  Sensor updates
  from other threads marshal via asio::post(io.get_executor(), ...).
  Same applies to set_*_change_handler callbacks (they fire on the
  io_context thread; observers must be thread-safe or hand work off).

- README.md §3 (Monitoring & observability): added a paragraph noting
  that hooks fire on the io_context thread, blocking I/O inside a
  handler stalls the dispatcher, and metrics exporters must respect
  the same contract.

- tests/test_thread_safety.cpp: two scenarios that exercise the
  canonical pattern — N producer threads asio::post sensor updates
  onto a worker-driven io_context; reads marshal back through the
  io.  Catches obvious regressions (e.g. someone adding a
  "convenience" cross-thread mutator that bypasses the strand).

A passing run isn't proof of race-freedom under ThreadSanitizer —
it pins down the *pattern* customers should follow.  TSan integration
is a separate workstream.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CMakeLists.txt

@@ -140,6 +140,7 @@ add_executable(secsgem_tests
   tests/test_e87_wire_scenarios.cpp
   tests/test_identifier_wildcards.cpp
   tests/test_concurrency.cpp
+  tests/test_thread_safety.cpp
 )
 target_link_libraries(secsgem_tests PRIVATE secsgem doctest::doctest)
 target_compile_definitions(secsgem_tests PRIVATE