working on target handling

work_note1

@@ -0,0 +1,59 @@
+What's Fixed (Good Work)
+  
+  - float height added to the master target_data_structure — now consistent with the SSBO and database.
+  - Thread count corrected to "five threads."
+  - Stale target rule fixed: "timestamp is older than 1 hour" — that's the right semantic.
+  - Database numbering gap (missing 5) is closed.
+  - int32_t police_boat properly typed in the database table.
+  - Database/dynamic state separation clarified — the note that the database holds only physical characteristics
+  is important and was missing before.
+  - patrol_route.json removed cleanly; simulator owns that logic now.
+  - Timing change resolves the A-scope problem I flagged — targets no longer have to wait for north crossing.
+
+  ---
+  One Significant New Issue
+
+  float elapsed_seconds will lose precision at current epoch.
+
+  float has roughly 7 significant decimal digits. The current Unix timestamp is about 1,748,000,000 seconds. At
+  that magnitude, a float can only distinguish values that are about 128 seconds apart — it cannot tell the
+  difference between two timestamps that are minutes or even an hour apart. Your 1-hour stale check would break
+  silently.
+
+  This should be int64_t elapsed_seconds (or simply keep the original time_t, which is int64_t on 64-bit Linux).
+  In the PostgreSQL column, this maps to BIGINT.
+
+  ---
+  Still Unresolved from Before
+
+  The SSBO struct (target_data_to_shader_structure, the block starting around line 142) still has the same
+  pseudo-types that were flagged earlier — enum material, binary police_boat, and time_t timestamp. The database
+  table was updated to proper types but the SSBO struct wasn't touched. Those three fields in the SSBO struct need
+   the same treatment:
+
+  - enum material; → int32_t material;
+  - binary police_boat → int32_t police_boat;
+  - time_t timestamp; → int64_t timestamp; — and note that std430 will align this to 8-byte boundaries, which may
+  pad the struct unexpectedly. Worth documenting.
+
+  Also: may_need_update in the database table still says "binary" rather than a typed value.
+
+  ---
+  One Question on the New Timing
+
+  With targets now dispatched "as they arrive," Thread 1 could receive a new target batch at any point during a
+  sweep — including mid-frame while the GPU is rendering. The mutex protects the write side, but you'll need to
+  decide when Thread 1 actually uploads the new data to the SSBO: at the start of each render frame (safest), or
+  immediately on receipt. "Immediately" is fine but should be stated, so the code is written with that in mind.
+  Recommend adding one sentence to the Thread 1 description about when it drains the incoming target buffer and
+  calls glBufferSubData.
+
+✻ Sautéed for 1m 1s
+
+※ recap: Museum radar simulator in C++/OpenGL. We're specifying the target data pipeline in CLAUDE.md. Next: fix 
+  the SSBO struct types — change enum material, binary police_boat, and time_t timestamp to proper int32_t and 
+  int64_t types. (disable recaps in /config)
+  
+──────────────────────────────────────────────────────────────────────────────────────────────────────────────────
+❯  
+───────────────────────────────────────────────────