Support running IntegrationKit builds in the Integration's namespace instead of the operator namespace

[wojciechgrazawskiahnl]

Requirement

When using Camel K in namespaced mode, IntegrationKit builds run in a short-lived builder Pod in the operator's namespace. In multi-tenant setups, application teams typically don't have access to the operator namespace, so when a build fails they can't view the builder Pod, its logs, or its events. This makes self-service debugging of build failures difficult.

It would be valuable to have a supported, non-deprecated way to run a build in the Integration's own namespace.

Questions

1. In the latest GA release, is there an officially supported way to have a build execute in the Integration's namespace rather than the operator's namespace?
2. With IntegrationPlatform deprecated and IntegrationProfile seemingly leaving builds in the operator namespace, is per-namespace build execution something the project intends to support? Is it on the roadmap?
3. If there's currently no supported path, would the project be open to a feature that makes this a first-class, per-Integration option?

Motivation

• Let application teams debug their own build failures (logs/events accessible in their own namespace) without needing operator-namespace access.
• Optionally, stronger build isolation between tenants.

[squakez]

Hello. Yes, this is going to be the way in the future builds. We have already moved in that direction for Integrations built from git (see #6389) and will be definitely the way when we introduce #6456. Mind that we'll be also moving to the direction of removing IntegrationKit #6455 exactly for the reasoning you've provided. The Build has to be a namespaced resource that the final user can get (only get, don't expect any manipulation).

I hope we can start tackling this soon, at least with some PoC.