chore: dd4hep-1.34

[wdconinc]

Briefly, what does this PR introduce?

This PR upgrade DD4hep to 1.34.

[Copilot]

Pull request overview

This PR upgrades the DD4hep detector description toolkit from version 1.33 to version 1.34 by adding the necessary cherry-pick from the spack-packages repository and updating the version constraint in the Spack environment configuration.

Changes:

• Added cherry-pick for DD4hep 1.34 from spack-packages repository
• Updated DD4hep version requirement from 1.33 to 1.34 in packages.yaml

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
spack-packages.sh	Added cherry-pick commit hash cfa8d65 with descriptive comment for DD4hep version 1.34
spack-environment/packages.yaml	Updated DD4hep version constraint from '@1.33' to '@1.34'

[veprbl]

Capybara is report is clean https://veprbl.github.io/capybara-reports/b2f42e1d040ac39d693d8d64d7437003/

[veprbl]

Let's merge after 26.02

[wdconinc]

Capybara is report is clean https://veprbl.github.io/capybara-reports/b2f42e1d040ac39d693d8d64d7437003/

Is this something we could turn into a CI check somehow?

[veprbl]

Capybara is report is clean https://veprbl.github.io/capybara-reports/b2f42e1d040ac39d693d8d64d7437003/

Is this something we could turn into a CI check somehow?

My way is too far from it. We could try to make capybara capy support gitlab and use it to make comparison benchmark.

[wdconinc]

Let's merge after 26.02

By now also 1.35 is out. Keep with incremental upgrade or jump by two minor versions at once?

[veprbl]

Once we merge this, we can submit 1.35 immediately after and then decide.