Fix checklist node in client print

[carlobeltrame]

Problem: I noticed that when reloading the print configurator page and then client printing a program with some activities with checklist nodes in it, the checklist nodes remain blank.

I then found out that inside client print some data is not properly preloaded before printing. Inside each checklist node, there is a _linked collection checklistItems: { href: /api/checklist_items?checklistNodes=/api/content_node/checklist_nodes/1a2b3c4d }. Although all individual checklist items are present in the store, this filtered collection is missing. For material nodes and their attached material items, we don't have this problem.

Detailed problem 1: In client print, we need this missing data to render the PDF correctly. This PR is an attempt to fix this problem, so that PDFs can be rendered complete with all content. I am doing this by embedding the checklist items in each checklist node, just like we already do with material items in material nodes.

Detailed problem 2: Currently, client print does not fail and report the error, but silently renders an empty Vue component, leaving an empty space in the PDF. This is due to Vue 3 aggressively catching errors which happen in setup functions, and not escalating them to outside the Vue app by default. This will be tackled in a separate PR #8128, so we get all errors in client print in sentry.

If we first solved detailed problem 2, then exporting pdfs would break. Therefore, I am first opening this PR and later a fix for detailed problem 2.

[BacLuc]

I think we had a reason to not do this:
See in EndpointPerformanceTest
2025-09-06T12:37:42.9347400Z -/activities/item: 35\n
2025-09-06T12:37:42.9348030Z +/activities/item: 37\n

can't we solve this in the frontend?
something similar than this:
#7747

[carlobeltrame]

Yes, looks like it introduces an n+1 problem. I don't fully understand why in the case of the material node we do not have an n+1, maybe because there it is a one-to-many relation instead of the many-to-many relation between checklist nodes <-> checklist items...?

Solving this in the frontend by preloading will result in n+1 API requests instead..
But I can maybe implement the filtering of checklist items by content node in the frontend instead of relying on the API for this.

[carlobeltrame]

I tried several different ways to solve this, which turned out not to work:

• Embed ChecklistItems in ChecklistNode. Although we do it similarly for MaterialItem in MaterialNode, for checklists this introduces n+1 DB queries. Maybe because the relation is many-to-many instead of one-to-many, didn't debug Doctrine / Api Platform deeply.
• Disabling the related collection link by removing the SearchFilter 'checklistNode' from ChecklistItem, but this SearchFilter was explicitely added in Feature/activity load selected checklist items as collection #7199 for performance reasons elsewhere in the app.
• Preloading the missing checklistNode.checklistItems() collections in the frontend leads to n+1 API requests, which is even worse.
• Loading all checklist items in the client print component and filtering them there has the problem that the camp is not available on the content node, and if we use all checklist items from /checklist_items, the list can quickly get very large.

So the only way I found that works is to provide camp to the client print rendering component, and then getting all checklists in the camp, all checklist items in the camp and from there finally get the filtered list of checklist items used in this checklist node.