Refactor SourceCache to TileManager

[wayofthefuture]

Summary

This PR refactors the SourceCache class to TileManager to better reflect its actual responsibilities within the rendering pipeline.

Rationale

The name SourceCache has been misleading and it significantly understates what this class actually does. After considering alternatives like SourceController and SourceManager, I believe TileManager to be the most accurate name.

What This Class Actually Does

Beyond simple caching:

• Tile Lifecycle Management - Creates, loads, unloads, and reloads tiles; manages state transitions (loading → loaded → reloading → expired → errored)
• Viewport-Driven Selection - Calculates ideal tiles for the current viewport, determines retention strategies for parent/child tiles, handles world wrap-around
• Direct Render Pipeline Integration - Called by Painter during render passes, provides renderable tile IDs to drawing functions
• Advanced Rendering - Implements raster and symbol fading, DEM backfilling for terrain, feature state updates across tiles

Why "TileManager"?

• Tiles are the primary concern - The class manages the lifecycle of Tile objects
• Manager pattern - It orchestrates multiple subsystems (source, cache, painter, terrain) around tile operations
• Pipeline integration - Deeply embedded in the rendering flow, not just a cache layer
• Broader scope - Makes high-level decisions about tile existence, loading, rendering, retainment, and disposal

Implementation & Notes

• Class renamed from SourceCache to TileManager
• All references updated throughout the codebase
• Variable names updated (e.g., sourceCache → tileManager)
• Filename changed to tile_manager.ts
• New directory called tile that includes tile_manager as well as the adjacent tile_ files.
• Create abstraction between source directory and tiles directory.
• Tees up the extension of this tile manager class to additional child classes based on source types.

[wayofthefuture]

💥

[HarelM]

Why are these defined here? are these static members?

[wayofthefuture]

A long running question I have had. The variables are also named backwards fyi.

[HarelM]

Can we move them inside the class and add a static modifier to them? I think this is a old javascript way of doing static variables...

[HarelM]

I saw that you merged the PR so consider doing this in a different PR then...

[wayofthefuture]

Sorry I didn't see these above! I'm about to open another PR in the next 5 min though... it should be draft a while so we can do it there... same file

[HarelM]

I've added mostly minor comments, thanks for making this happen!

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 96.29%. Comparing base (166724b) to head (df6edbf).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #6635   +/-   ##
=======================================
  Coverage   96.29%   96.29%           
=======================================
  Files         293      293           
  Lines       35475    35481    +6     
  Branches     8688     8691    +3     
=======================================
+ Hits        34160    34166    +6     
  Misses       1315     1315           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[HarelM]

I had a radical idea to make everything that is not used outside the class "private".
But it would probably break all kind of plugins not to mention the tile manager tests that relay heavily on private members.
But probably outside the scope of this PR...

[HarelM]

Nice work! Thanks!

[wayofthefuture]

BOOM?

[HarelM]

BOOM!