Let authors pick any form from their Jobber account

[faisal-alvi]

Description of the Change

Jobber accounts can now have any number of forms rather than one booking form and one request form, so the block lets an author pick which form to display instead of choosing between two hardcoded types.

Consumes the middleware's new GET /jobber/forms endpoint. The legacy /jobber/graphql path is untouched, so blocks saved before this change keep rendering the form they were set to and show a notice in the editor asking for a form to be chosen. Nothing is changed on their behalf.

Iframe height follows Jobber's BookingType enum: JOB and ASSESSMENT create a booking and use the shorter height, NONE is request only and uses the taller one.

Depends on 10up/jobber-node#58. The middleware must be deployed before this is released, otherwise the request falls through to the /jobber/* wildcard and returns 400.

How to test the Change

1. composer install, then npm ci && npm run build.
2. Connect a Jobber account and insert the Jobber block. The sidebar should list every enabled form, with the account default labelled and preselected.
3. Switch forms and confirm the preview updates, and that a booking type form renders shorter than a request only form.
4. Publish and confirm the selected form renders on the front end.
5. Open a page that used the block before this change. It should render as before and show a notice asking for a form to be picked.
6. Deactivate the plugin and confirm no jobber_query_* transients or options remain.

No Jobber account is needed: the jobber_pre_query filter can return tests/test-plugin/get-forms.json, which is what the Cypress suite does.

Changelog Entry

Added - Choose any form from the connected Jobber account, rather than only a booking or a request form.
Changed - Blocks added before this update keep displaying the form they were set to, and prompt for a form when edited.

Credits

Props @faisal-alvi, @jjgrainger

Checklist:

• I agree to follow this project's Code of Conduct.
• I have updated the documentation accordingly.
• I have added Critical Flows, Test Cases, and/or End-to-End Tests to cover my change.
• All new and existing tests pass.

[faisal-alvi]

The three Cypress jobs are failing here for a reason that predates this branch, so flagging it rather than papering over it.

composer update -W fails to resolve in the E2E workflow (conflicts around 10up/phpcs-composer ^3.0 and automattic/vipwpcs). That step is continue-on-error: true, so the job continues with no vendor/ directory. The plugin then hits its own guard in jobber.php:

if ( ! is_readable( JOBBER_PLUGIN_PATH . 'vendor/autoload.php' ) ) {
	// admin notice
	return;
}

It returns before registering anything, so no settings page exists and options-general.php?page=jobber_settings returns 403. Every spec that visits it fails on that.

Evidence this is not from these changes:

• a2-connect-to-jobber.test.js fails the same way, and this branch does not touch it. Only a1-plugin-activation.test.js passes, as it does not need the plugin's own pages.
• The E2E workflow has run on develop once, in August 2025, at bfa029e, which is the commit this branch is based on. It has not run since, and the dependency tree has drifted.

So the suite was already broken on develop and this PR is simply the first thing to run it in a year.

The fix belongs in CI rather than in these specs: either drop continue-on-error from the composer step so a resolution failure fails loudly instead of silently producing a broken environment, or pin the dev dependencies so composer update -W resolves again. Happy to raise that separately so it does not expand the diff here into dependency territory.

Worth being explicit about the consequence: the new specs in this PR have not actually been exercised. They fail before reaching their assertions, so they are written but unproven until the environment issue is sorted.