Assert the altitude a location carries, and stop claiming a strictness four ports lack

[ergofobe]

Release preparation for v0.5.0. Two significants from the pre-release cumulative review of v0.4.1..HEAD, both zero-behaviour changes. Closes no issue — this is the "fix what the cumulative review found, then tag" step.

1. conformance/ never asserted location.altitude

59baede and 1dea642 moved three ports (Rust, Kotlin, Swift) from decoding GeoPoint as a unit to rebuilding it field by field from a private Wire struct. All three copy altitude correctly — but nothing checked. The bounds fixture's assert block listed latitude, longitude and place only, while its payload carries altitude: 2835.0.

So dropping altitude from any of those three mappings passed all thirty-six fixtures in all five ports while every asset silently lost its altitude. That is precisely the failure CONTRIBUTING says the round-trip assert exists to catch — "a field the type forgot, which would otherwise decode fine and vanish on the way back out".

Verified rather than assumed. With altitude: wire.altitude replaced by altitude: None in the Rust mapping:

assertion `left == right` failed: assetLocationAtTheBounds.location.altitude: expected 2835.0, got null
test result: FAILED. 15 passed; 1 failed

Before this change that mutation was green. The assert counts rise accordingly — TypeScript 322 → 323 expect() calls, Swift 228 → 229 checks.

2. The new docstring claimed a strictness four ports do not have

All five ports gained the line "Only the response path gives: GeoPoint stays strict wherever a client sends one." That is true in TypeScript, where GeoPoint is z.number().min(-90).max(90). In Rust, Python, Kotlin and Swift it is a bare f64/float/Double pair with no range check, so AssetUploadMetadata and UploadSessionCreate will send latitude: 200 without complaint.

Since #27 made every port drop an out-of-range location on the way back, the round trip is now silently lossy from those four: upload a coordinate, read it back as location: null, with nothing anywhere saying why. imogen-cli already reimplements the bounds check itself because the Rust port does not — and its manifest path bypasses even that.

The comment in each port now names which port is strict and points at #40, where the actual asymmetry is tracked. Adding request-path bounds to the four is a behaviour change and belongs there, not in a release-prep PR.

Verification

All five ports, from this branch:

port	result
TypeScript	162 pass, 0 fail (323 expect calls)
Rust	tests + clippy --all-targets + fmt --check clean
Python	53 passed, ruff check + format clean
Swift	229 conformance checks passed
Kotlin	BUILD SUCCESSFUL

Found, not fixed

The same review surfaced three pre-existing items, all now filed and none gating this release: #36 (favorite: z.coerce.boolean() reads the string "false" as true — a live data bug that ships in v0.4.1 today), #37 (Swift is the last port with an unescaped upload filename), #39 (the TypeScript conformance suite silently skips ten of thirty-six fixtures), and #40 (the request-path asymmetry above).

🤖 Generated with Claude Code