Confidential Space launcher `/v1/token` returns empty response for `AWS_PRINCIPALTAGS` without `aws_principal_tag_options`

## Summary

When the Confidential Space launcher receives `POST /v1/token` with `token_type="AWS_PRINCIPALTAGS"` but without the companion `aws_principal_tag_options` field, it closes the Unix-domain-socket connection without writing an HTTP response. `curl` reports `Empty reply from server` and `HTTP=000`.

Other malformed requests to the same endpoint return clean `400 Bad Request` responses. This makes the missing-options case look like a launcher or socket failure instead of a request validation error.

## Environment

- Confidential Space debug image, observed `swversion=260400`
- GCP `c3-standard-4`, Intel TDX
- Endpoint: `/run/container_launcher/teeserver.sock` from inside the workload container
- Reproduced on 2026-05-01

## Reproduction

From inside a Confidential Space workload container:

```bash
curl -sv --max-time 12 \
--unix-socket /run/container_launcher/teeserver.sock \
http://localhost/v1/token \
-H content-type:application/json \
-d '{"audience":"https://x","token_type":"AWS_PRINCIPALTAGS"}' \
-w '\nHTTP=%{http_code}\n'
```

Observed:

```text
> POST /v1/token HTTP/1.1
> content-type:application/json
> Content-Length: 57
>
HTTP=000
* Empty reply from server
* Closing connection 0
```

The same behavior also occurs when a valid-length `nonces` array is present:

```json
{"audience":"https://x","token_type":"AWS_PRINCIPALTAGS","nonces":["AAAA1111AAAA1111AAAA1111AAAA1111AAAA1111A"]}
```

## Expected Behavior

The launcher should return a clean `400 Bad Request`, for example:

```text
aws_principal_tag_options is required when token_type=AWS_PRINCIPALTAGS
```

This would match the existing validation behavior for other malformed inputs.

## Comparison Cases

| Request shape | Observed result |
|---|---|
| Valid `AWS_PRINCIPALTAGS` with `aws_principal_tag_options` | `HTTP=200`, AWS-shaped token returned |
| Missing `aws_principal_tag_options` | `HTTP=000`, empty response |
| Missing `aws_principal_tag_options` plus `nonces` | `HTTP=000`, empty response |
| Empty body `{}` | `HTTP=400`, `use GET request for the default identity token` |
| Typo inside companion field, `allowed_principal_tag` singular | `HTTP=400`, `json: unknown field "allowed_principal_tag"` |

## Source-Level Observation

From a source read, the launcher POST path validates JSON parsing, non-empty `audience`, and non-empty `token_type`, then forwards the request to the attestation path. For `AWS_PRINCIPALTAGS`, missing `aws_principal_tag_options` appears to be accepted locally and passed downstream instead of being rejected at the launcher boundary.

I do not have a stack trace, so I am not claiming a specific panic root cause. The observed issue is the externally visible behavior: the UDS connection closes with no HTTP response for this malformed request shape.

## Impact

- Reachability: local workload container only, via `/run/container_launcher/teeserver.sock`.
- Security impact observed: none.
- Launcher process survives; subsequent valid requests still work.
- Integrator impact: confusing failure mode. A malformed request is indistinguishable from a launcher/socket failure unless compared against other validation paths.

This is a low-severity robustness issue. A validation check before entering the AWS principal-tags path should be sufficient.

Start at the launcher’s POST /v1/token handling and trace the AWS_PRINCIPALTAGS path after JSON parsing. Reproduce the missing aws_principal_tag_options request over the Unix socket, then verify that malformed requests return HTTP 400 rather than closing the connection; add or update coverage if the relevant test location is found.

Written by the indexing model from the issue text.