feat(template): Generate NOTES.txt for every operator chart

[lfrancke]

Draft, for discussion. This shows what generating NOTES.txt from the template looks like, as an alternative to the per-repo copies now landing in each operator.

The plumbing is one file and no new configuration

README.md.j2 already varies on exactly the three things NOTES.txt needs, so this reuses its idioms verbatim:

Expression	Purpose	Overridden by
operator.pretty_string	product name in the sentence	—
operator.product_string	documentation slug	—
operator.hub_component_slug | default(operator.product_string)	Hub slug	only spark-k8s, which is spark
operator.config.has_product | default(true)	the gate described below	commons, listener, secret

No change to config/repositories.yaml.

The special case

commons, listener and secret have has_product: false. They own no product custom resource and have no Hub component page, so they get different prose and no Hub link.

They also need chart_title rather than pretty_string, because their pretty_string already ends in "Operator". Without that the sentence reads "the Stackable operator for Stackable Secret Operator" — the same doubling that chart_title was introduced to fix for the chart headings.

Rendered:

This installs the Stackable operator for Apache Hive only.        # has_product
This installs the Stackable Secret Operator only.                 # has_product: false
It provides resources that the product operators consume, so there is nothing further to apply.

Verified

Rendered all 16 and checked each product-name line and both links. The docs slug equals product_string for every operator, including the three whose docs module is <name>-operator, so no per-operator mapping is needed.

Output is byte-identical to the NOTES.txt already merged in stackabletech/hive-operator#753 and stackabletech/kafka-operator#1013, and to the files in the open stackabletech/trino-operator#935 and stackabletech/zookeeper-operator#1080. So the next rollout adds the file to twelve charts and shows no diff for those four.

A generated NOTES.txt also renders correctly through helm install --dry-run for a has_product: false chart, which is the path the per-repo copies have never exercised.

One caveat on the verification: ansible-playbook is currently broken on this machine (Local RPC server did not start, Python 3.14 against this build), so the render used Jinja2 configured with the settings ansible.builtin.template applies — trim_blocks on, lstrip_blocks off, keep_trailing_newline on, and the delimiters playbook/update_repo.yaml passes. Worth re-running through the real playbook before this is merged, since mismatched Jinja settings are what caused #620.

Trade-off worth deciding

Generating it means the wording is one edit for all 16 instead of 16 edits. It also means an operator cannot tailor its own notes without an ignored_files entry. The three has_product: false charts already show that the prose does not generalise perfectly; if more operators end up wanting their own wording, the conditional grows and the per-repo file becomes the simpler option.