fix(storage): give the compat fromTask an explicit return type

[armando-navarro]

Fixes #3677

This gives the compat fromTask an explicit return type, so the published @angular/fire/compat/storage typings stop depending on how the typings bundler names an inferred Firebase type.

Changes

• fromTask in src/compat/storage/observable/fromTask.ts declares Observable<UploadTaskSnapshot>. The type is unchanged: UploadTaskSnapshot is the compat alias for firebase.storage.UploadTaskSnapshot.
• Removes a comment explaining a firebase import that add eslint #3421 removed in 2023.
• Once this merges, it will be cherry-picked to 20.1.x, so a 20.1 patch release fixes @angular/build: TS2307: Cannot find module 'firebase/compat' #3677 for apps on the latest tag.

Why

Without a declared return type, the typings import whatever module path the bundler picks for the inferred type:

• 20.0.1 and 20.1.0 import 'firebase/compat'. The firebase package's exports map has no ./compat entry, so apps using moduleResolution: "bundler" fail with TS2307: Cannot find module 'firebase/compat'. Angular's use-application-builder migration switches apps to that setting, which is how @angular/build: TS2307: Cannot find module 'firebase/compat' #3677 ran into it.
• 21.0.0-rc.1 happens to import 'firebase/compat/app', which resolves, so it compiles.
• ng-packagr 22.2, which the Angular 22 upgrade brings in, bundles typings with rolldown-plugin-dts. It cannot parse the inferred type, and the library build fails with PARSE_ERROR in fromTask.d.ts.

Verification

• A consumer importing fromTask, compiled with tsc 5.9.3 and moduleResolution: "bundler": the 20.0.1 and 20.1.0 typings fail with the error in @angular/build: TS2307: Cannot find module 'firebase/compat' #3677, and the 21.0.0-rc.1 typings and this branch's build compile. With node10 resolution all of them compile, which matches the report that the older builder works.
• main with the Angular 22 upgrade applied (Angular 22.2.1, ng-packagr 22.2.4) fails to build with PARSE_ERROR in fromTask.d.ts, and builds once the return type is added.

There are no new tests, since a declared return type has no runtime behavior. The Angular 22 build covers it once that upgrade lands.

[tyler-reitz]

LGTM, with one suggestion.

Checked the chain against the artifacts rather than the description. The 20.0.1 and 20.1.0 typings do declare fromTask returning a type imported from 'firebase/compat', firebase's exports map lists ./compat/app but no ./compat, and that import is TS2307 under moduleResolution: "bundler" while compiling fine under node10, which matches the report that the older builder works. 21.0.0-rc.1 imports 'firebase/compat/app', so it resolves. The build from this branch emits Observable<UploadTaskSnapshot> and imports only resolvable paths, and since the emitted typings alias UploadTaskSnapshot to firebase.storage.UploadTaskSnapshot, the public type is unchanged. I did not reproduce the ng-packagr 22.2 PARSE_ERROR.

The suggestion: the return type is load-bearing and nothing now says so. Deleting the old comment is right, the import it described is gone, but a later cleanup could drop the annotation as redundant and quietly bring #3677 back. The existing fromTask spec pins the element type by assigning each snapshot to a firebase.storage.UploadTaskSnapshot, but that type is identical either way, so it cannot catch how the emitted typings spell it, and by your own note the real coverage arrives with the Angular 22 build. A line like "declared so the typings do not import an inferred firebase/compat path, see #3677" would hold the fix in place.