FIO-11561: Enable MCP server to use form revisions

[blakekrammes]

Description

Ticket https://formio.atlassian.net/browse/FIO-11561

This PR enables the MCP server to utilize form revisions. It adds only two new tools: form_revisions_list and form_revision_get. For the rest of the form revision functionality, the existing form_* tools have been modified to support it.

The main highlights are:

1. Added form_revisions_list, form_revision_get
2. form_create enables form revisions by default (original)
3. form_update includes a note on what changed for every form mutation (note is ignored if the deployment/form doesn't enable revisions)
4. If revisions are not enabled on the license used by the deployment (i.e. no Security Module), the user is prompted to acknowledge (for both form_create and form_update) that they will be executing form mutations without history (the user is prompted once for all sessions per deployment/base url)
5. If revisions are enabled on the deployment, but form_update is executing against an existing form that does not have revisions enabled, the user is prompted to either enable revisions or knowingly proceed without mutation history (if the user declines enabling revisions, they are prompted once per form per session)
6. A user can revert to a prior revision with form_update

Opinionated Decisions

Draft Publish and Revision Revert Flows

In the Formio developer portal, both the draft publish and revision revert flows use PUT form/:formId and update only a subset of properties on the form. I opted to emulate that behavior for the MCP server. We could opt to make every property draft-updatable and revertible, but I assume (perhaps wrongly) that there were reasons that these choices were made for the portal. For instance, perhaps it would be undesirable to revert a form’s submission access or form settings when the only intention is to return to a prior form component schema.

This of course does not limit what can be updated through the standard form update (not using a draft).

Draft Publish Flow

A draft form is simply a revision (a document in the Mongo formrevisions collection). In the current PR, the draft save and publish flows only allow updating the following subset of fields from the draft revision. This list was compiled from:

1. The subset of properties overlaid from the draft onto the live form when editing a draft in the portal. ['components', 'settings', 'tags', 'properties']. I believe it should also take 'display' from the draft (since 'display' is one of the revertible properties––see below). I think there’s a bug in the portal here. When the draft is saved, only these fields are updated, the rest of the form remains untouched.
2. The subset of properties used to determine if a new revision should be created. This adds ['controller', 'esign'] to the list of properties that can be updated in a draft flow in the MCP server.

So, the full set of properties used by the MCP server:

ai/packages/mcp-server/src/revisions/flows.ts

Lines 5 to 13 in c76d1e2

	export const DRAFT_FIELDS = [
	'components',
	'settings',
	'tags',
	'properties',
	'controller',
	'esign',
	'display',
	] as const;

Revision Revert Flow

Similarly, the reversion flow takes only a subset of fields from a past revision document and leaves the rest of the document properties as they are on the latest/live form. This is the list of properties taken from the revision when reverting to a prior revision in the portal.

ai/packages/mcp-server/src/revisions/flows.ts

Line 15 in c76d1e2

export const REVERT_FIELDS = ['components', 'tags', 'properties', 'display'] as const;