fix(android): use float division for download progress ratio

[armamini]

Problem

On Android, the count option of .progress() is silently ignored for downloads:

ReactNativeBlobUtil.config({ path: dest })
  .fetch('GET', url)
  .progress({ count: 10 }, (written, total) => { /* ... */ });

No matter what count is set to, callbacks arrive on the interval schedule only. iOS honours count correctly, so the same JS produces different callback cadence per platform.

Root cause

Three sites compute the progress ratio using long / long, which is integer division. The result truncates to 0 for the entire transfer and only reaches 1 on the final read:

// ReactNativeBlobUtilFileResp.java:141
float progress = (contentLength() != -1) ? bytesDownloaded / contentLength() : ...;

// ReactNativeBlobUtilDefaultResp.java:70
reportConfig.shouldReport(bytesRead / contentLength())

// ReactNativeBlobUtilReq.java:220  (DownloadManager polling)
float progress = (total > 0) ? written / total : 0;

Assigning to a float happens after the truncation, so the cast never helps.

ReactNativeBlobUtilProgressConfig.shouldReport gates the count throttle on the ratio being positive:

public boolean shouldReport(float progress) {
    boolean checkCount = true;
    if (count > 0 && progress > 0)
        checkCount = Math.floor(progress * count) > tick;
    boolean result = (System.currentTimeMillis() - lastTick > interval) && enable && checkCount;
    ...
}

Since progress is always 0, count > 0 && progress > 0 is never true, checkCount keeps its default of true, and the count bucket is never consulted. Reporting degrades to interval-only.

The upload path already gets this right — ReactNativeBlobUtilBody.java:438 reads config.shouldReport((float) written / contentLength) — so the intended semantics are unambiguous; the three download sites simply missed the cast.

Fix

Cast to float before dividing, at all three sites:

• Response/ReactNativeBlobUtilFileResp.java — download-to-file responses
• Response/ReactNativeBlobUtilDefaultResp.java — in-memory responses
• ReactNativeBlobUtilReq.java — DownloadManager polling loop

DefaultResp additionally guards the chunked case, where contentLength() is -1 and the old expression yielded a negative ratio. Old and new code both take the interval-only path there, so this is a clarification rather than a behaviour change.

Compatibility

Usage	Before	After
.progress(fn) (count -1)	interval-only	unchanged
.progress({ interval: N }, fn)	interval-only	unchanged
.progress({ count: N }, fn)	count silently ignored	count honoured
Upload progress	already correct	unchanged

No public API change. iOS and Windows are untouched.

Verification

Download a file large enough to span many reads with .progress({ count: 10, interval: 0 }, fn) and count the callbacks: previously they tracked the interval only; now they arrive at roughly each 10% boundary, and written advances monotonically to Content-Length.