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_

先检查 /var/log/cloud.log 和 storage.resource.HttpUploadServerHandler 中的 SSVM 日志证据，然后跟踪 local-upload 请求从 UI 经过浏览器、代理或负载均衡器以及 Apache 路径的完整流程。在检查 SIGNATURE、METADATA 和 EXPIRES 是否得到保留的同时，重现间歇性 upload。完成标准是本地 upload 能够始终携带有效 header 到达 SSVM，而不是返回 HTTP 432。

由索引模型根据 Issue 内容生成。