fix: signal-backed marker reactivity and stale signal re-push

Two issues discovered during testing:

1. data-effect expressions for signal-backed markers short-circuited
   before reading $signalID when the map hadn't loaded yet. Datastar
   never tracked those signals as dependencies, so the effect never
   re-ran. Fix: read signal values unconditionally before the guard.

2. prepareSignalsForPatch never reset changed=false on regular signals
   (only computed ones), causing every SyncSignals() call to re-push
   all signals — including stale server-side values for the draggable
   pin, overwriting the client-side drag position.

context.go

@@ -291,6 +291,7 @@ func (c *Context) prepareSignalsForPatch() map[string]any {
 			}
 			if sig.changed {
 				updatedSigs[sigID.(string)] = fmt.Sprintf("%v", sig.val)
+				sig.changed = false
 			}
 		case *computedSignal:
 			sig.recompute()

maplibre/js.go

@@ -233,12 +233,15 @@ func dragendHandlerJS(mapID, markerID string, mk Marker) string {
 // markerEffectExpr generates a data-effect expression that moves a signal-backed marker
 // when its signals change.
 func markerEffectExpr(mapID, markerID string, mk Marker) string {
+	// Read signals before the guard so Datastar tracks them as dependencies
+	// even when the map/marker hasn't loaded yet on first evaluation.
 	return fmt.Sprintf(
+		`var lng=$%s,lat=$%s;`+
 			`var m=window.__via_maps&&window.__via_maps[%s];`+
 			`if(m&&m._via_markers[%s]){`+
-			`m._via_markers[%s].setLngLat([$%s,$%s])}`,
-		jsonStr(mapID), jsonStr(markerID), jsonStr(markerID),
+			`m._via_markers[%s].setLngLat([lng,lat])}`,
 		mk.LngSignal.ID(), mk.LatSignal.ID(),
+		jsonStr(mapID), jsonStr(markerID), jsonStr(markerID),
 	)
 }