request feature : Add default namespace for all Kubernetes resources & auto‑PVC creation for resources with DefaultStorageClassName

Description:
Currently, our Kubernetes manifests do not consistently specify a namespace, and some workloads that require persistent storage do not have PVCs automatically created when a DefaultStorageClassName is available.
Proposed changes:
- Default Namespace
- Define a single default namespace (e.g., webApp-system or webApp-app) in our manifests.
- Ensure all Kubernetes resources (Deployments, Services, ConfigMaps, Secrets, etc.) explicitly set metadata.namespace to this default namespace.
- Update CI/CD templates and Helm charts (if applicable) to inject the namespace automatically.
- Persistent Volume Claims for DefaultStorageClassName
- Detect resources (e.g., container workloads, databases) that require persistent storage.
- If a DefaultStorageClassName exists in the cluster, automatically create a PVC for these workloads using that storage class.
- PVC naming convention: -pvc or -pvc.
- PVC size and access modes should be configurable via values or environment variables.
Benefits:
- Consistent namespace usage across all resources.
- Reduced risk of deploying into the wrong namespace.
- Automatic storage provisioning for workloads without manual PVC creation.
- Improved deployment automation and reduced human error.
Acceptance Criteria:
- [ ] All manifests explicitly set metadata.namespace to the default namespace.
- [ ] PVCs are automatically created for workloads with DefaultStorageClassName.
- [ ] PVC configuration is customizable (size, access mode).

api :
` var kube = builder.AddKubernetesEnvironment("k8s").WithDefualtNamespace("namespace");`

Additional Notes:
- Ensure backward compatibility for existing deployments.
- Consider adding a migration script to move existing resources into the default namespace if needed.

Start by inspecting the Kubernetes manifests, CI/CD templates, Helm charts, and the AddKubernetesEnvironment API mentioned in the issue. Determine how namespaces and storage requirements are currently represented before defining a backward-compatible approach. Done means resources use a configurable default namespace and eligible workloads receive configurable PVCs with the stated naming convention.

Written by the indexing model from the issue text.