Fix #6675: disable builder.tasks injection via operator env var

[HarshMehta112]

Summary

Adds an operator-level toggle to enable or disable custom pipeline task injection via the
builder.tasks trait, preventing CR authors from running arbitrary build containers in
environments where that capability should be restricted.

How it works:

Set BUILDER_TASKS_ENABLED=false on the operator deployment to disable custom tasks:

BUILDER_TASKS_ENABLED=false

• When unset or any value other than "false" → custom tasks are allowed (backward compatible, no behavior change)
• When set to "false" (case-insensitive) → builder.tasks values are ignored; an info message is logged

When disabled the pod-strategy validation is also skipped, so CR authors do not receive a misleading "use pod strategy" error for tasks that will never run.

Changes

• pkg/platform/env_platform.go — new BuilderTasksEnabled() reads BUILDER_TASKS_ENABLED; returns true by default
• pkg/trait/builder.go — gate in Apply() wraps determineCustomTasks call; logs at info level and skips when disabled
• pkg/platform/env_platform_test.go — 5 tests covering not-set, "true", "false", "FALSE", and empty-string cases
• pkg/trait/builder_test.go — TestBuilderTraitTasksDisabledByOperator (pipeline has no custom tasks when disabled) and TestBuilderTraitTasksEnabledByDefault (tasks flow through when var is unset)
• docs/modules/ROOT/pages/installation/builds.adoc — BUILDER_TASKS_ENABLED added to build env var table
• docs/modules/traits/pages/builder.adoc — "Custom Pipeline Tasks" section added with NOTE about the operator gate

Test plan

• make test passes locally
• TestBuilderTasksEnabled_* (platform) — env var parsing and boolean logic
• TestBuilderTraitTasksDisabledByOperator — verifies no custom tasks in pipeline when BUILDER_TASKS_ENABLED=false
• TestBuilderTraitTasksEnabledByDefault — verifies tasks work normally when var is unset
• Manual: deploy operator with BUILDER_TASKS_ENABLED=false; apply an Integration with builder.tasks set; confirm no custom container in builder pod and info log emitted

Fixes #6675

[squakez]

Thanks for the work. I think we need a minor adjustment and always allows the quarkus-native which is hardcoded by the same trait. So, we need to check the existence of that task and keep it if available, whilst skipping the reset if the flag is disable.

[HarshMehta112]

Thanks for the work. I think we need a minor adjustment and always allows the quarkus-native which is hardcoded by the same trait. So, we need to check the existence of that task and keep it if available, whilst skipping the reset if the flag is disable.

Done. When BUILDER_TASKS_ENABLED=false, applyTasksFilter() now iterates t.Tasks and retains
any entry whose name (first ;-delimited field) is quarkus-native — the operator-injected task —
while dropping and logging every other entry. If no user tasks are present the filter is a no-op.

[squakez]

Good for now. However I am realizing there is some work we need to do around the presence of the quarkus-native task. I'll create a follow up issue to work on it separately.

[github-actions]

✔️ Unit test coverage report - coverage increased from 62.7% to 62.8% (+0.1%)

[HarshMehta112]

Hi @squakez
CI failures in common/common are unrelated to this PR. Both failing tests (TestPipeWithImage/run_with_new_image, TestStructuredLogs) are cluster/environment issues — builder-specific tests all passed.
Could a you please re-trigger?