fix(studio-server): address PR #2097 review feedback on relative-timing resolver

Documents the shared-pattern context (3rd copy of "resolve relative
data-start", after runtime startResolver.ts and the SDK's own
getElementTimings) and explains when the raw parseFloat fallback in
resolveStart's else branch can actually fire (a malformed grammar string
with a leading number). Adds a test pinning the "reference target exists
but its own timing is unresolvable" branch, which existing tests didn't
cover (only "target doesn't exist" was tested).

Cross-checked the negative-offset clamp concern raised in review: the
SDK's own resolveReferenceStart (session.ts) also clamps to
Math.max(0, ...), so this stays consistent with its sibling — no code
change needed there.

packages/studio-server/src/helpers/previewAdapter.test.ts

@@ -293,6 +293,18 @@ describe("T10 — PreviewAdapter contract (spec for R7)", () => {
       expect(timings["hf-orphan"].start).toBeUndefined();
     });
 
+    it("returns undefined start when the reference target exists but its own timing is unresolvable", () => {
+      make("div", { "data-hf-id": "hf-untimed" }); // no data-end, no data-duration
+      make("div", {
+        "data-hf-id": "hf-outro",
+        "data-start": "hf-untimed + 2",
+        "data-duration": "1",
+      });
+      const adapter = adapterWith(() => null);
+      const timings = adapter.getElementTimings();
+      expect(timings["hf-outro"].start).toBeUndefined();
+    });
+
     it("terminates (not an infinite loop) on a mutual A <-> B reference cycle", () => {
       make("div", { "data-hf-id": "hf-a", "data-start": "hf-b", "data-duration": "2" });
       make("div", { "data-hf-id": "hf-b", "data-start": "hf-a", "data-duration": "3" });