feat(fetchMap): support polygon fill patterns

[zbigg]

Phase 2 of line & polygon styling: polygon fill patterns. Stacked on #297 (stroke dash styles) so a temporary prerelease cut from this branch carries both. Retarget to main once #297 lands.

Data-only fetchMap integration — parse-map emits accessors + flat props + scales; the consumer spreads descriptor.props and deck.gl does the rest. No @deck.gl/* imports.

• getFillPatternAccessor (by-column) → ${pattern}-${density} keys; solid/none density-agnostic; unmapped → transparent none.
• fillPatternEnabled toggle, atlas/mask props, getFillPattern + scales.fillPattern; tint rides the existing getFillColor. ScaleKey += fillPattern; new FillPatternRange + visConfig/visualChannels types.

Fill-pattern atlas — editable tiles assembled at runtime (+ baked comparison)

deck.gl's fillPatternAtlas/fillPatternMapping are async props (they accept a Promise), resolved internally (same machinery as data/iconAtlas). So the atlas builder stays internal — parse-map sets result.fillPatternAtlas = getPatternAtlas() and the consumer contract never changes (just spreads descriptor.props).

Two implementations behind a runtime switch:

• B — runtime (the approach we want): the patterns live as individual, developer-editable assets — 22 real 64×64 tiles under src/fetch-map/patterns/*.png, one per pattern+density (+ solid) — not a compiled blob. tsup inlines each (dataurl loader); the assembler composites them into the 192×512 sheet on a canvas at first render, memoized as a Promise. Verified pixel-identical to the Design master (0 / 98304 px differ).
• A — baked (comparison): the same sheet frozen to one base64 data URL. Sync, no runtime deps, but a compiled blob you can't edit.

Switch (PoC): globalThis.__CARTO_RUNTIME_ATLAS__ = true selects B; default A. Both render identical Design art.

The asset format (PNG now vs SVG later) is a deferred experiment; the vector master is kept out of the repo for now.

Tests: parse-map + layer-map specs (69 pass, type-checked); full suite green; prettier + eslint clean.

[gemini-code-assist]

Code Review

This pull request introduces support for polygon fill patterns using an inlined base64 sprite atlas. It adds accessor functions, configuration types, and parser logic to handle both single and by-column fill pattern modes, along with comprehensive unit tests. A review comment identifies a critical issue in single mode where density is unconditionally appended to the pattern key, potentially producing invalid keys like 'solid-medium' or 'none-medium' that do not exist in the atlas mapping.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

In single mode, if visConfig.fillPattern is 'solid', 'none', or undefined, constructing the key by unconditionally appending the density (e.g., ${visConfig.fillPattern}-${density}) will result in invalid keys like 'solid-medium', 'none-medium', or 'undefined-medium'. These keys do not exist in PATTERN_ATLAS_MAPPING and will cause rendering issues or sample the wrong atlas cell.

We should resolve the key using the same logic as getFillPatternAccessor (treating 'solid' and 'none' as density-agnostic, and falling back to 'none' if undefined).

        // Single mode: one real pattern (never solid/none) for every feature.
        const pattern = visConfig.fillPattern ?? 'none';
        const key =
          pattern === 'solid' || pattern === 'none'
            ? pattern
            : pattern + '-' + (fillPatternDensity ?? 'medium');
        result.getFillPattern = () => key;