fix(files): pass the SDK's AccountDownloadToken to the stream URL builder

[altaywtf]

Fixes the red main build: putio-sdk-kotlin#69 changed buildOriginalStreamUrl to take AccountDownloadToken, and CI builds the SDK from its main branch, so FilesWatchedRepository.kt:72 stopped compiling ("actual type is 'String', but 'AccountDownloadToken' was expected").

• SdkFilesStreamUrls now passes the account's AccountDownloadToken through instead of unwrapping it to a string.
• Drops the comment about the SDK's old accessToken parameter name.
• ./gradlew verify passes locally against putio-sdk-kotlin main (Temurin 21).

---

Written by an agent (Claude Code, Opus 5.5)

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, add credits to your account and enable them for code reviews in your settings.

[Copilot]

Copilot review overview

🟢 Approval recommended

A minimal, correct type fix that forwards the SDK's AccountDownloadToken wrapper, consistent with existing codebase patterns and covered by existing tests.

Review effort: Balanced
Findings: None

What changed in this PR

This PR fixes a compilation failure on the main branch caused by an upstream SDK change (putio-sdk-kotlin#69) where buildOriginalStreamUrl was changed to accept an AccountDownloadToken instead of a String. Since CI builds the SDK from its main branch, FilesWatchedRepository.kt stopped compiling because it was unwrapping the token to its string .value. The fix passes the AccountDownloadToken wrapper through directly.

Changes:

• Updates the buildOriginalStreamUrl lambda signature in SdkFilesStreamUrls to take AccountDownloadToken and forwards the token wrapper without unwrapping .value.
• Adds the AccountDownloadToken import and removes the now-stale comment about the SDK's old accessToken parameter name.

File	Description
app/​src/​main/​kotlin/​io/​putdotio/​android/​files/​FilesWatchedRepository.kt	Passes the SDK's AccountDownloadToken to the stream URL builder instead of unwrapping it to a String, restoring compilation against the new SDK signature.

I verified the change is consistent and correct:

• AccountInfo.downloadToken is typed AccountDownloadToken?, and after the null check at line 80 the value is smart-cast to non-null AccountDownloadToken, matching the updated lambda parameter type.
• This mirrors the existing pattern in PlaybackRepository.kt:185, which already passes AccountDownloadToken directly to PlaybackMediaCredential.downloadToken(...).
• The internal constructor lambda is only reached through the public SdkFilesStreamUrls(client) constructor; no other call site constructs it with the old string signature, and tests use the FilesStreamUrls fun interface directly.
• Existing coverage in SdkFilesStreamUrlsTest exercises the real SDK path end-to-end and asserts the resulting URL carries the download token (never the access token), and the Ready.toString() redaction remains intact.

No issues found.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.