[dmt] feat: add helmignore coverage rule

[fuldaxxx]

Description

• helmignore in the static scope now validates only the file itself: it exists, it says something, its patterns are well formed. The package-root coverage scan it also ran is gone from the source tree.
• A new helmignore-coverage rule joins the bundle scope. It walks the bundle image root and reports entries that no .helmignore pattern excludes — the files Helm would otherwise pull into every chart packed from the module. Reported at warn; severity is tunable through the remote.bundle section.
• Chart material needs no pattern and is exempt: templates/, charts/, monitoring/, Chart.yaml, values.yaml, plus the build-generated images_digests.json, which exists in no source tree and so can never be named by a hand-written .helmignore.
• The four e2e fixtures that covered the old static coverage scan are removed. The e2e framework drives scopes.Static only, so a bundle-scope rule has no fixture path there; unit tests cover it instead.

Against a real published module (.helmignore listing crds docs enabled hooks images lib Makefile openapi *.md release.yaml werf*.yaml NOTES.txt, bundle assembled by the standard werf template):

🐒 [helmignore-coverage (#module)]
     Message:      File 'changelog.yaml' is present in the bundle image and is not listed in .helmignore
     Module:       r-g-test
     Object:       bundle
     FilePath:     changelog.yaml

🐒 [helmignore-coverage (#module)]
     Message:      File 'module.yaml' is present in the bundle image and is not listed in .helmignore
     Module:       r-g-test
     Object:       bundle
     FilePath:     module.yaml

🐒 [helmignore-coverage (#module)]
     Message:      File 'oss.yaml' is present in the bundle image and is not listed in .helmignore
     Module:       r-g-test
     Object:       bundle
     FilePath:     oss.yaml

Why do we need it, and what problem does it solve?

The helmignore rule failed CI on files CI itself had written into the checkout. Anything a job drops in the module root before dmt lint runs — a build cache, a generated manifest, a scratch artifact — read as is not listed in .helmignore, and the module owner had nothing to fix.

The root cause is that the coverage half of the rule asked a question about what a module ships, but asked it of the working tree. The working tree is not what ships: werf assembles the bundle image from an includePaths allowlist, so a scratch file never reaches the image in the first place, and .helmignore only governs what does. The rule was reading the wrong tree.

So the fix follows the scope boundary rather than patching the scan. What is answerable from the file alone stays on static, where a developer still catches a broken pattern locally with one dmt lint. The tree comparison moves to bundle, where the tree is the built image and holds only what werf let through — no CI scratch, and every finding describes a file that actually reached the registry.

An inverted formulation was built first and dropped: nothing .helmignore excludes may still be present in the image. It cannot work, because nothing ever applies .helmignore to an image — Helm applies it when packing a chart, werf never does. Every deliberately-shipped-but-ignored path (hooks/, openapi/, crds/, docs/: the metadata Deckhouse reads off the module filesystem rather than through Helm) was therefore a false positive, and silencing them took a 13-entry allowlist of legitimate paths. With that allowlist complete the rule had no reachable finding left.

The accepted trade-off: an uncovered root file that includePaths never ships is no longer reported at all. That file costs nothing — not a byte in the chart, no risk in a cluster — and in exchange the rule stops failing builds over files the module never publishes.

Signed-off-by: Ruslan Gorbunov ruslan.gorbunov@flant.com