fix(sync): store latestVersion in state and omit it from PATCH

[TimKrieg01]

Summary

Keep Vapi's latestVersion as per-resource state metadata instead of storing it in resource configuration, capture it from pulls and push responses, and never send it in tool, assistant, or squad PATCH payloads.

Why

There are two separate drift problems this change addresses:

1. Apply/push leaves a stale local version. Applying a config change can advance a Vapi resource from v6 to v7; the PATCH response contains latestVersion: v7, but the local resource file remains at v6. The baseline then reflects v7 while the file still reflects v6, so a later audit can incorrectly report local-ahead even when the actual config matches. Writing the returned version back into the resource file could fix this symptom, but would keep server metadata mixed into authored config.
2. Version-only differences look like config drift. latestVersion describes the current Vapi-side version state; it is not desired assistant, tool, or squad configuration. For example, a dashboard change is published as v7, then reverted and published as v8, while local v6 has the same config as v8. Including the version in the resource hash can falsely report dashboard-ahead; if there is also a separate local edit, the version-only delta can make the classifier report a false both-diverged conflict. Store the version beside the UUID in the state file and compare resource config without it.

The API also rejects latestVersion when sent in a tool PATCH. A direct PATCH API-request test tool with only its current version returned:

PATCH /tool/<test-tool-id>
Content-Type: application/json

{"latestVersion":"v2"}

400 Bad Request
{"message":["property latestVersion should not exist"],"error":"Bad Request","statusCode":400}

A GET immediately afterward still reported latestVersion: v2 and the same updatedAt, so the rejected probe did not change the tool.

Changes

• Store each resource's latestVersion beside its UUID in .vapi-state.<org>.json, keeping version metadata out of the resource file and its content hash.
• For example, the state entry becomes "my-tool": { "uuid": "<uuid>", "latestVersion": "v8" }; the tool YAML contains only the desired tool configuration.
• Capture the version returned by Vapi during pulls and successful creates or updates, so local state follows the platform after sync.
• Exclude latestVersion from PATCH payloads for tools, assistants, and squads. This prevents the Vapi tool PATCH validation error and avoids sending server-managed metadata as authored config.
• Preserve the metadata through state serialization and migration, while continuing to accept legacy UUID-only entries.

Verification

• npm run build
• npm test (544 tests passed)
• Manual live sync checks covered tool updates, assistant prompt changes, and dashboard rollback scenarios. Tool version advances were recorded in .vapi-state.<org>.json; assistant edits that Vapi kept as drafts did not advance latestVersion. A rollback that restored a config matching an earlier version did not produce version-only drift or a merge conflict.
• Live Vapi API probe confirmed that a tool PATCH containing latestVersion returns 400 Bad Request with property latestVersion should not exist.