Producers upload whole tracks, not 60s clips. Before, a large file was either
413-rejected at the edge or buffered wholesale in RAM (upload read + content
hash + engine decode each copied the whole file). Now ingest, hashing and the
signal/loudness engines all stream in bounded windows, so peak memory is
O(window) not O(file) and a big upload can't OOM the shared box.

- engines/streaming.py: probe() + windows() — bounded window iterator over the
  whole file at native SR (soundfile streams WAV/FLAC/OGG/MP3, exact frames).
- onsets/waveform/spectrum: full-track. waveform/spectrum aggregate EXACTLY
  (fixed output grid filled by a streaming reduction); onsets concatenates
  per-window onset envelopes (tiny) for near-exact global tempo/hits.
- loudness: full-track; peak/true-peak/RMS/crest exact, integrated LUFS
  energy-weighted across windows (pyloudnorm gating can't merge chunks exactly)
  and flagged approximate:true / lufs_method:chunked.
- clip-tier (emotion/features/samples/analyze/grade/naming) stay head-analysis
  (a 5-min track's 'sample role' is meaningless) but every response now carries
  an honest source{duration_s,sr,channels,size_bytes} block.
- app ingest streams the upload to disk (never one big read); size ceiling read
  per-request. content_id streams the decode-to-hash, byte-identical to the old
  whole-file hash so the deployed cache stays warm. Upload cap 40->100MB to
  match the gateway.
- tests: test_fulltrack.py proves >60s coverage, content_id stability, exact
  streaming reductions, contiguous windowing. Full suite green (parity w/ base).