feat: forward service env to service targets and make it round-trip safe

[JeffreyCA]

This PR builds on #8936 (forward service env to extensions, tracked by #9008) and hardens the service-level env forwarding so it is complete, environment-aware, and safe to round-trip back into azure.yaml.

Context

#8936 forwarded expanded service env to framework providers, but left gaps that made it incomplete and unsafe for extensions that persist config.

• Service target providers still received a ServiceConfig with no environment.
• Get / GetResolvedServices resolved against the default environment (ignoring -e), and nested conversions dropped the resolver, so GetProject expanded service env to empty strings.
• Incoming values were wrapped as templates on the way back in, so a value like pa$$word could be reinterpreted, and an AddService round-trip baked resolved values into azure.yaml, discarding the author's ${VAR} templates.

Changes

Service target providers now receive resolved env, via a shared serviceConfigToProto(lazyEnv, serviceConfig) helper used by both external provider types.

Environment resolution is now uniform and honors -e. Get / GetResolvedServices resolve through a single envResolver() backed by the session lazyEnv, the resolver is propagated into nested service conversions, and a missing environment expands to empty strings instead of failing.

Round-trips back into azure.yaml are safe. Incoming values are wrapped with osutil.NewLiteralExpandableString (escaping $ and \), and AddService preserves the original ${VAR} template for every env entry whose expanded value is unchanged.

Docs explain reading versus authoring. ServiceConfig.environment carries expanded values for providers to read, while raw ${VAR} templates are authored through the env path of the service config RPCs (GetServiceConfigSection / SetServiceConfigSection, or the Value variants).

Behavior at a glance

Scenario	On #8936	With this PR
Service target provider reads serviceConfig.Environment	not populated	resolved against the active environment
GetProject service-level env	expands to empty strings	expanded against the active environment
Get / GetResolvedServices environment	default environment, ignores -e	active session environment, honors -e
AddService round-trip of an unchanged env entry	template lost or baked to its resolved value	${VAR} template preserved
Env value containing $ (for example pa$$word)	can be reinterpreted	preserved verbatim

Using it as an extension author

A provider reads already-expanded values from serviceConfig.Environment:

// serviceConfig.Environment is resolved against the active azd environment (honors -e).
endpoint := serviceConfig.Environment["API_ENDPOINT"]

Given env: { API_ENDPOINT: ${SERVICE_API_ENDPOINT} }, a read-modify-write through ServiceConfig keeps the template intact (unchanged entries are not baked to their resolved values):

resp, _ := client.Project().Get(ctx, &azdext.EmptyRequest{})
svc := resp.Project.Services["api"]
svc.Host = "containerapp" // change something unrelated to env
_, _ = client.Project().AddService(ctx, &azdext.AddServiceRequest{Service: svc})

To author or edit a raw ${VAR} template, use the service config RPCs instead of AddService, since ServiceConfig.environment only carries expanded values (escape a literal $ as $$):

_, _ = client.Project().SetServiceConfigValue(ctx, &azdext.SetServiceConfigValueRequest{
    ServiceName: "api",
    Path:        "env.API_ENDPOINT",
    Value:       structpb.NewStringValue("${SERVICE_API_ENDPOINT}"),
})

Testing

• Mapper coverage for forward, reverse, round-trip, and nested conversions, including env values that reference the environment, static values, and values containing $.
• osutil.NewLiteralExpandableString coverage for template syntax, $, backslashes, and UNC paths.
• Framework and service target provider conversions, including per-call resolution and the empty-values fallback.
• Project service coverage for environment-aware resolution and template preservation on AddService.