tests: migrate the remaining ITs onto the Harmonia + Java stack

[delchev]

Context

#6587 got the IT fixtures off the AngularJS templates, which is all that was needed to unblock #6588. It did not migrate them onto the Harmonia + Java stack — the tests still exercise TypeScript handlers and, for the BPM forms, the AngularJS form builder. This issue is that second half.

Transaction ITs — CamelTransactions{Commit,Rollback}IT, QuartzTransactions{Commit,Rollback}IT

Today, after #6587: edm.gen generates with template-application-schema (the BOOK table and nothing else) and the handlers insert through the SDK Update facade in TypeScript.

• Quartz can migrate now. A Quartz handler does not have to be JS/TS — a @Component implements org.eclipse.dirigible.sdk.job.JobHandler with cron() + run() is the sanctioned client-Java form (shipped in templates: client-Java counterparts for the Job, Listener and WebSocket starters #6581), and it can write through the generated BookRepository, which is what CLAUDE.md requires for entity CRUD. That means repointing edm.gen to template-application-ui-harmonia-java/template/template.js, replacing jobs/test-job.job + jobs/test-job-handler.ts with a Java handler, and dropping the .job descriptor (a self-describing Java handler needs none).
  • Watch the log assertion: QuartzTransactions*TestProject waits on LogsAsserter("app.out", …) for "test-job-handler.ts: test entities are saved". A TS console.log lands on the app.out logger; an SDK Logging.getLogger("<pkg>.<Class>") lands on app.<pkg>.<Class> instead, so the asserter's logger name and the expected message both have to change.
• Camel cannot migrate until camel: client-Java route handlers and Java Camel starter templates #6586. The Dirigible Camel integration only invokes JS/TS (dirigible-java-script), so the Camel handler stays TypeScript until the dirigible-java component exists. Do it as part of camel: client-Java route handlers and Java Camel starter templates #6586, which already has to convert the Camel starter templates.
• Once the handlers write through a generated repository again, consider whether schema-only or the full Harmonia+Java stack is the right generation target for each test.

BPM form ITs — ApproveLeaveRequestBpmIT, DeclineLeaveRequestBpmIT, BpmnMultitenancyIT

Three .gen descriptors still name template-form-builder-angularjs, so #6588 cannot remove that template until this is done.

Repointing to template-form-builder-harmonia is not just a string change — the generated page differs:

• Output path is the same (gen/{{genFolderName}}/forms/{{fileName}}/index.html), and input ids are still the model's own (fromId, toId), so openPath and enterTextInElementById should hold.
• The date control differs. Harmonia renders input-date as a plain <input type="text"> inside x-h-date-picker, with x-model bound to the picker popup, not the input. fillLeaveRequestForm types 02/02/2002 straight into #fromId, which may not reach model.fromDate. The form's code pre-seeds both dates with new Date() and the email assertion only matches an ISO-shaped date, so the test could pass while silently no longer testing the typed value.
• The alert path should survive: the .form code calls the native alert(...), which Browser.assertAlertWithMessage picks up via Selenide.switchTo().alert(), and the Harmonia form builder's $scope / $http shims run the existing AngularJS code unchanged.

Run these ITs for real when making the change — they are @Tag("ui"), so the PR gate (!ui | smoke) does not cover them.

Acceptance criteria

• No IT fixture references template-form-builder-angularjs; template-application-* references are Harmonia/Java or schema only.
• The Quartz transaction ITs assert against a Java handler writing through the generated repository.
• ApproveLeaveRequestBpmIT, DeclineLeaveRequestBpmIT and BpmnMultitenancyIT pass against the Harmonia form, with the date actually bound from what the test enters.
• templates: remove the AngularJS and TS application-stack templates #6588 can then remove template-form-builder-angularjs.

---

Part of #6591.

[delchev]

Narrowing the BPM-form risk: the upstream x-h-date-picker contract says the input is not display-only.

x-model placement: on x-h-date-picker-popup, not the input.
User input: users can both pick from the calendar and type directly — "manual input typed by the user is parsed using the configured display format", with a fallback to the native Date constructor.
Model value: always YYYY-MM-DD, regardless of display format. The input's own value holds the formatted display text.

So fillLeaveRequestForm's enterTextInElementById("fromId", "02/02/2002") should bind after all — my earlier concern (that x-model sitting on the popup made the text input inert) was wrong.

Two notes that remain:

• The display format defaults to the user's locale, so a typed date is locale-sensitive in general. BPMLeaveRequestIT happens to be immune: 02/02/2002 and 03/03/2002 are identical under DD/MM and MM/DD. Any new date literal in these fixtures should keep that property, or set the format explicitly.
• Still unverified: whether Selenide's sendKeys fires the event the picker parses on. That is what an actual run settles.