add support for shm_size

[madejackson]

This PR enables support for shm_size in servapps.

I tested it on my system and also tested if it works for imports and backups, and it does.

[madejackson]

What commit 17e69eb does

Aligns Cosmos's shm_size handling with Docker Compose's upstream behavior.

The problem: Docker Compose specifies shm_size as a byte-value string — e.g. "64mb", "1gb", "512kb" — but Cosmos stored and transmitted it as a raw integer byte count (int64). The compose importer even actively destroyed the unit by parsing the string to a number before sending it, so shm_size: 64mb would silently become raw bytes.

The fix:

• src/docker/api_blueprint.go — ContainerCreateRequestContainer.ShmSize is now a string; parsed to raw bytes at container-create time via units.RAMInBytes(), mirroring the existing mem_limit/mem_reservation handling.
• src/docker/export.go — formats the daemon's raw byte count back into a compact {amount}{unit} string on export, so round-tripped services/exports behave identically to the original compose file.
• client/.../docker-compose.jsx — stops coercing shm_size to a number; keeps the byte-size string (bare numbers still normalized to a raw-byte string for backward compat).
• go-sdk/client.gen.go — DockerContainerCreateRequestContainer.ShmSize updated to *string to match.

Result: shm_size behaves the same as docker-compose — "64mb", "1gb", "512kb" etc. are accepted and preserved, and existing compose files / exports round-trip correctly.