[PWGHF] Remove unsafe reserve in charm FemtoDream producers

[zhangbiao-phy]

EDIT by @vkucera : Mitigates fatal caused by AliceO2Group/AliceO2#15450

[github-actions]

O2 linter results: ❌ 0 errors, ⚠️ 0 warnings, 🔕 0 disabled

[alibuild]

Auto-approving on behalf of @zhangbiao-phy.

[vkucera]

Hi @zhangbiao-phy , can you please briefly describe in the PR description the problem that this is solving?

[zhangbiao-phy]

Hi @zhangbiao-phy , can you please briefly describe in the PR description the problem that this is solving?

Hi @vkucera, This PR fixes a runtime fatal error triggered by the stricter reserve() checks introduced recently from this PR： 473e398.

In these FemtoDream charm producers, the reconstructed charm candidate outputs were reserved with candidates.size() for a per-collision filtered candidate range. In some workflows this size can be zero while the range still yields a candidate during iteration, leading to errors such as:

Table 'FDHfCand2Prong': filled 1 rows after reserve(0)

Since the candidate range size is not a reliable upper bound for the number of rows filled in these tasks, this PR removes the unsafe reserve() calls for the reconstructed charm candidate output tables.