templates: the task form's COMPLETE path still prints the raw error message, and the #7271 IT walk cannot see it (#7263 follow-up)

[delchev]

Describe the bug

PR #7271 (#7263) routes the admin page, the my/partner list and calendar loads, the report page and the task form's generic submit() through apiErrors.refusalMessageFor, and the guide now says "A generated page never shows e.message". The path every process user task actually takes still does.

FormIntentGenerator emits the .form code (intent/generator/form/FormIntentGenerator.java:470-482):

$http.post('/services/inbox/tasks/' + __taskId, { action: 'COMPLETE', data: __data })
  .then(...)
  .catch((error) => {
      const message = error && error.data && error.data.message ? error.data.message : 'Unknown error';
      __notifications.show({ type: 'negative', title: 'Submit failed', description: message });
  });

and the $http shim in template-form-builder-harmonia/ui/form.js.template:86 feeds it the raw text:

.catch((e) => { throw { data: { message: e && e.message }, status: e && e.httpStatus }; });

NotificationHub.show -> ctx.notify(title + ': ' + description) -> x-text="message" on the form. So a 500 from POST /services/inbox/tasks/{id} (a repository throwing inside the check gate, a constraint the 409 mapper does not know) prints the Hibernate/JDBC sentence on the task form - the surface #7263 was about - while the submit() the PR fixed is, per its own comment, only the "generic submit for forms declaring a metadata URL and no explicit handler", which an intent-generated form never uses.

The IT walk added for it cannot see this: IntentEmissionCoverageIT:2994-2997 flags a page only when it contains (e && e.message) or String(e.message. The fixture's four user tasks emit gen/emission/forms/*/form.js with message: e && e.message } (no parentheses) and error.data.message - neither pattern matches, so the walk passed over the very files that carry the defect. The rule is asserted for two spellings, not for the property.

Expected

• The $http shim throws an object that carries the parsed error (errorType/httpStatus, as ApiError does) and the generated .catch renders it through refusalMessageFor(error, 'Submit failed.'), so a task form shows the authored refusal or the neutral fallback, never a stack-trace sentence.
• The IT asserts the property instead of two spellings: no e.message / error.data.message read outside apiError.js in anything under gen/, including forms/*/form.js.