Expose documented Kubernetes pre-serialization and deployment extension points

### Is there an existing issue for this?

- [x] I searched the existing issues

Related issues:

- #19680 demonstrates why depending on the internal `prepare-deployment-targets-{environment}` step is brittle.
- #16378 requests similar publisher extensibility for Docker Compose.
- #18097 covers the related but broader problem of deploy-time values produced by running resources.

### Is your feature request related to a problem? Please describe the problem.

Third-party integrations sometimes need to replace Aspire's default Kubernetes configuration/secret emission with a target-native or external mechanism such as Consul Template, External Secrets, or another secret agent.

A concrete example is a connection string containing both:

- Kubernetes endpoint values that must be translated to the target service DNS name and port.
- Secret values that should be emitted as Consul Template expressions instead of a Kubernetes `Secret` and Helm values references.

The integration needs a supported point where deployment-target values have been translated, but the generated Kubernetes objects have not yet been serialized to disk.

`PublishAsKubernetesService(...)` is currently the closest public API. The implementation invokes it after `KubernetesResource.ProcessResourceAsync(...)` has processed endpoints, environment variables, arguments, ConfigMaps, and Secrets, and before `WriteKubernetesTemplatesForResource(...)` serializes them. However, that timing and the state of the generated model are not documented as a compatibility contract.

`WellKnownPipelineSteps.PublishPrereq` does provide stable pipeline ordering before publisher steps. The Kubernetes `publish-{environment}` step depends on it, so a custom step that is `requiredBy` `PublishPrereq` can run before serialization. If the custom step also depends on `WellKnownPipelineSteps.ProcessParameters`, it can run after parameter processing. A step that instead depends on `PublishPrereq` is only a sibling of the Kubernetes publisher and may run concurrently with it.

That solves the basic ordering problem, but the customizer still receives the already-flattened generated model. For example, connection strings are available through `Secret.StringData` as strings containing Kubernetes/Helm expressions. There is no public API to translate an arbitrary `ReferenceExpression` using the Kubernetes publisher's endpoint and port allocation rules while preserving structured secret references. `IComputeEnvironmentResource.GetHostAddressExpression(...)` and `GetEndpointPropertyExpression(...)` help with individual endpoint properties, but do not replace the publisher's complete value translation.

As a result, integrations still have to parse and rewrite flattened Helm expressions or reimplement Kubernetes endpoint and connection-string translation.

### Describe the solution you'd like

1. Document the lifecycle and guarantees of `PublishAsKubernetesService(...)`, including whether it is guaranteed to run after target value translation and immediately before serialization.
2. Document the `ProcessParameters` -> custom step -> `PublishPrereq` ordering pattern for integrations that need an async, service-aware pre-publish operation.
3. Provide an async, typed pre-serialization customization context that exposes the source resource, generated Kubernetes resource, services/model, cancellation token, and structured target-translated environment/secret values.
4. Allow customizers to suppress or replace Aspire's default ConfigMap/Secret generation without manually repairing workload references.
5. Expose a supported helper for translating a `ReferenceExpression` through the selected compute environment while preserving parameters and secret references.

A documented example that replaces a generated Kubernetes Secret with an external secret/template provider would validate the API end to end.

### Additional context

The existing `PublishAsKubernetesService(...)` callback and `WellKnownPipelineSteps.PublishPrereq` may already be the right foundation. The main gaps are their documented timing/contracts, access to structured translated values before they are flattened, and a supported way to replace default secret/config emission.

Start with PublishAsKubernetesService(...), KubernetesResource.ProcessResourceAsync(...), and WriteKubernetesTemplatesForResource(...) to map the current translation and serialization lifecycle. Then inspect WellKnownPipelineSteps.PublishPrereq and ProcessParameters, including the ordering described in the issue. Done should include documented contracts and a supported typed pre-serialization customization path that preserves structured values and allows default ConfigMap/Secret emission to be replaced.

Written by the indexing model from the issue text.