Local Template/ISO Upload Fails - SSVM receives SIGNATURE=null

### problem

**Related Issue**
This is related to #12486 but represents a distinct root cause.

**Summary**
When uploading templates/ISOs from local file via the UI, the SSVM sometimes receives requests with SIGNATURE=null instead of the valid signature. This causes immediate validation failure with HTTP 432 error, and the upload never completes.
The root cause (whether the browser fails to send the header, or something strips it in transit) requires further investigation.

### versions

- Management Server: Rocky Linux 8 / RHEL based
- SSVM: Debian-based SystemVM template 4.20.2.0
- Browser: Chrome Version 144.0.7559.59 (Official Build) (64-bit)

### The steps to reproduce the bug

1. Navigate to Images → Templates (or ISOs)
2. Click "Upload Template from local"
4. Fill in template details (name, hypervisor=KVM, format=QCOW2, etc.)
5. Select a file and submit
6. Observe HTTP 432 error in browser console
7. Check SSVM logs - may show SIGNATURE=null

Note: This issue is intermittent and difficult to reproduce consistently.

**Expected Behavior**
The SSVM should receive valid SIGNATURE, METADATA, and EXPIRES headers with every upload request.

**Actual Behavior**
The SSVM sometimes receives SIGNATURE=null, causing immediate validation failure.

**Workaround**

- Retry the upload (may work on subsequent attempts)
- Use URL-based template registration instead of local upload

**Analysis**
The SSVM definitively received requests with SIGNATURE=null. Further investigation is needed to determine where in the chain the signature is lost:

- Browser fails to attach the header
- Proxy/load balancer strips the header
- Apache on SSVM fails to forward the header
- Race condition in UI JavaScript code

The issue is intermittent, which suggests a timing or race condition.

**Evidence**

- SSVM Logs (/var/log/cloud.log) - Shows SIGNATURE=null received

```
2026-01-21T15:35:12,754 INFO [storage.resource.HttpUploadServerHandler] (nioEventLoopGroup-3-2:[]) HEADER: SIGNATURE=null
2026-01-21T15:35:12,779 ERROR [storage.resource.HttpUploadServerHandler] (nioEventLoopGroup-3-2:[]) post request validation failed com.cloud.exception.InvalidParameterValueException: signature, metadata and expires are compulsory fields.
2026-01-21T15:35:18,548 INFO [storage.resource.HttpUploadServerHandler] (nioEventLoopGroup-3-3:[]) HEADER: SIGNATURE=null
2026-01-21T15:35:18,554 ERROR [storage.resource.HttpUploadServerHandler] (nioEventLoopGroup-3-3:[]) post request validation failed com.cloud.exception.InvalidParameterValueException: signature, metadata and expires are compulsory fields.
2026-01-21T15:35:49,917 INFO [storage.resource.HttpUploadServerHandler] (nioEventLoopGroup-3-4:[]) HEADER: SIGNATURE=null
2026-01-21T15:35:49,923 ERROR [storage.resource.HttpUploadServerHandler] (nioEventLoopGroup-3-4:[]) post request validation failed com.cloud.exception.InvalidParameterValueException: signature, metadata and expires are compulsory fields.
```

- Browser Console Error

```
Failed to load resource: the server responded with a status of 432 (432)
Error: Request failed with status code 432
```

- Management Server Logs - Misleading Error Message

The management server shows a misleading "Couldn't find ssvm" error even though the SSVM is running and healthy:

```
2026-01-21 15:22:16,171 DEBUG [o.a.c.s.e.DefaultEndPointSelector] (Upload-Monitor-1:[ctx-e41f2a9e]) (logid:0531e27c) Couldn't find ssvm for urlhttps://10.0.56.181/upload/78e32075-e9e2-4d91-b40b-6b6f65e59165
2026-01-21 15:23:16,255 DEBUG [o.a.c.s.e.DefaultEndPointSelector] (Upload-Monitor-1:[ctx-0c36c949]) (logid:1e37cd87) Couldn't find ssvm for urlhttps://10.0.56.181/upload/78e32075-e9e2-4d91-b40b-6b6f65e59165
2026-01-21 15:24:16,316 DEBUG [o.a.c.s.e.DefaultEndPointSelector] (Upload-Monitor-1:[ctx-b52f89e1]) (logid:0587fffd) Couldn't find ssvm for urlhttps://10.0.56.181/upload/78e32075-e9e2-4d91-b40b-6b6f65e59165
```

- Database Verification - SSVM was Running and Up

```
mysql> SELECT id, uuid, name, public_ip_address, private_ip_address, status FROM host WHERE type='SecondaryStorageVM';
+----+--------------------------------------+--------+-------------------+--------------------+--------+
| id | uuid | name | public_ip_address | private_ip_address | status |
+----+--------------------------------------+--------+-------------------+--------------------+--------+
| 4 | 2cf2f703-cb23-4ed1-909e-4ad47ed22919 | s-1-VM | 10.0.56.181 | 10.0.40.156 | Up |
+----+--------------------------------------+--------+-------------------+--------------------+--------+
```

- Template State After Failed Upload

```
{
"id": "78e32075-e9e2-4d91-b40b-6b6f65e59165",
"name": "Linux Debian 12",
"isready": false,
"status": "NotUploaded",
"downloaddetails": []
}
```

- No Files Created on SSVM:

```
root@s-1-VM:~# ls -la /mnt/SecStorage/5f75abe3-3803-3595-89ad-52d23b3dea97/template/tmpl/2/202/
ls: cannot access '/mnt/SecStorage/5f75abe3-3803-3595-89ad-52d23b3dea97/template/tmpl/2/202/': No such file or directory

root@s-1-VM:~# grep -i "78e32075-e9e2-4d91-b40b-6b6f65e59165" /var/log/cloud.log
(no output - template UUID never reached SSVM)
```

### What to do about it?

_No response_

Start with the SSVM log evidence in /var/log/cloud.log and storage.resource.HttpUploadServerHandler, then trace the local-upload request from the UI through the browser, proxy/load balancer, and Apache path. Reproduce the intermittent upload while checking whether SIGNATURE, METADATA, and EXPIRES are preserved. Done means local uploads consistently reach the SSVM with valid headers instead of HTTP 432.

Written by the indexing model from the issue text.