No template-level deactivation: templates can only be started or fully deleted

[fantasywind]

Context

An admin screen needs to take an approval template out of service: no new instances may be started from it, while instances already in flight finish on the workflow snapshot they were submitted with.

Current behaviour

TemplateService exposes activate / deactivate / delete for categories only:

activateApprovalTemplateCategory(id)
deactivateApprovalTemplateCategory(id)
deleteApprovalTemplateCategory(id)

For templates themselves there is no equivalent. ApprovalTemplateEntity has a deletedAt column but no service method sets it, and there is no isActive / status field. listApprovalTemplates({ status }) filters by ApprovalTemplateListStatusEnum (DRAFT / PUBLISHED), which is derived from version state rather than from an explicit lifecycle flag.

Why this matters

The only host-side approximations are both lossy:

• Archive the published version. Blocks submission, but the version history now reads as if the template were never in service, and re-activating means republishing — which produces a new version number for a change that was purely administrative.
• Keep a separate "deactivated template" list in the host. Works, but it is a second source of truth for template lifecycle sitting outside the library that owns templates.

Suggested fix

Add an explicit lifecycle flag on the template plus the two service methods:

deactivateApprovalTemplate(id: string): Promise<ApprovalTemplateEntity>;
activateApprovalTemplate(id: string): Promise<ApprovalTemplateEntity>;

with submitApprovalInstance rejecting a deactivated template, and in-flight instances unaffected (they already run from workflowSnapshot).

[fantasywind]

Why template-level activation/deactivation is needed, not just a caller-side check

We worked around the missing template-level deactivation by archiving the template's current version (currentVersionId still points at it). That is enough to stop the engine accepting new submissions, but it turns out not to be enough on its own.

TemplateMutations and ComposeTemplateMutations register publishApprovalTemplateVersion, rollbackApprovalTemplateVersion and composeApprovalTemplateWithForm(publish: true) on the same GraphQL schema as the host application. Any of the three flips the archived version back to PUBLISHED and makes the template launchable again. This is not a hand-crafted API call: TemplateDesignerView from @rytass/bpm-core-react calls them from its own "save and publish" button, so a user who has the designer open on a deactivated template silently re-enables it.

Two things would help:

1. Template-level activate/deactivate on TemplateService (mirroring the existing category-level pair), so the state is owned by the engine and every publish path respects it, rather than each host re-deriving "is this template disabled" from version status.
2. An audit/lifecycle hook on these three mutations. They currently write no audit record of any kind, so "who re-published this template and when" is unanswerable from the host side. We had to wrap them in an interceptor purely to get that.

Happy to send a PR for either if that's useful.