[aranega]

Implemented solution

Introduces an entity-graph model representing a CloudHarness project's apps, images, tasks, and config layering, replacing the previous dict/function-based generator.

Helm chart, Codefresh pipeline, Skaffold, Tilt, docker-compose, and VS Code debug-config generation are all rebuilt on top of this model instead of the old ad-hoc traversal code.

This PR completes the migration: the new model (formerly ch_cli_tools/ng/) is now the
only implementation. harness-deployment is the single entrypoint, and the old dict-based generator, its parallel test suite, and harness-deployment-legacy have been ported after verifying line-by-line parity against the legacy test suite (full history and exact removals/gaps in PORT_NOTES.md attached to the PR).

Notable fixes that came out of building/verifying the new model:

• Codefresh pipeline path resolution no longer mis-locates the repo root when run from a
  double-nested checkout path (e.g. GitHub Actions' work/<repo>/<repo>/), which previously
  pointed generated scripts at the wrong working directory.
• Test images (e.g. test-e2e, test-api) now get a real content-hash tag instead of
  falling back to latest, so they correctly trigger rebuilds when their content changes.
• Directory hashing/scanning (used for build-trigger content hashes) no longer walks into
  ignored directories like node_modules before filtering, and content hashing uses
  xxhash instead of SHA1 for a large speedup on big trees (~19x faster measured on a huge file structure).
• Packaging migrated from setup.py/requirements.txt to pyproject.toml.

Not a breaking change for deployed CloudHarness projects. Generated Helm/Codefresh/Skaffold/Tilt/compose output is intended to match the legacy generator's output for all existing configurations covered by the test suite.

How to test this PR

Run the full test suite from tools/deployment-cli-tools:

micromamba run -n hfo2 python -m pytest tests/ -q

All tests should pass (no known failures).

For an end-to-end sanity check against a real project, run harness-deployment against
an actual deployment (e.g. the natus-hfo-tools project) and confirm it completes
successfully and produces the expected Helm chart / Codefresh pipeline / Skaffold config:

harness-deployment cloud-harness . -l -d hfo.local -dtls -n hfo -e local -i portal -i accounts

Sanity checks:

• The pull request is explicitly linked to the relevant issue(s)
• The issue is well described: clearly states the problem and the general proposed solution(s)
• In this PR it is explicitly stated how to test the current change
• The issue seta the scope and the type of issue (bug, story, task, etc.)
• The relevant components are indicated in the issue (if any)
• All the automated test checks are passing
• All the linked issues are included in one Sprint
• All the linked issues are in the Review state
• All the linked issues are assigned

Breaking changes (select one):

• The present changes do not change the preexisting api in any way
• This PR and the issue are tagged as a breaking-change and the migration procedure is well described above

Possible deployment updates issues (select one):

• There is no reason why deployments based on CloudHarness may break after the current update
• This PR and the issue are tagged as alert:deployment (this is a refactoring of the deployment feature, so it's worth checking any deployment issue)

Test coverage (select one):

• Tests for the relevant cases are included in this pr
• The changes included in this pr are out of the current test coverage scope

Documentation (select one):

• The documentation has been updated to match the current changes
• The changes included in this PR are out of the current documentation scope

Nice to have (if relevant):

• Screenshots of the changes
• Explanatory video/animated gif

PORT_NOTES.md