Dynamic feed and map icons

[newmanw]

Summary

Feed and map icons are currently locked to whatever a service adapter hardcodes — there's no way for an admin to pick a custom icon for a feed or its map markers without shipping code. This PR makes feed/map icons dynamic and admin-configurable end to end: pick a registered icon, point at a source URL, or upload a file directly from the feed edit UI, with icons persisted server-side and rendered consistently across the feed panel, feed items, and the map.

What changed

Service

• New static_icons Mongo collection (migration 032-add-static-icon-collection) with a unique/sparse index on sourceUrl, and a new STATIC_ICON_WRITE permission granted to ADMIN_ROLE.
• entities.icons / app.api.icons / app.impl.icons extended with a StaticIconStoreError type and richer error plumbing (iconSourceUrlFetchError now handles null and store errors, not just URL resolution failures) so failures fetching or storing icon content surface as proper InfrastructureErrors instead of being swallowed as invalid input.
• adapters.icons.content_store.file_system, adapters.icons.controllers.web, and adapters.icons.db.mongoose updated to support the new storage/lookup paths, with corresponding test coverage added/expanded.
• app.impl.feeds / app.ts wire the icon service into the feed pipeline so a feed's mapStyle.icon is no longer restricted to a source-URL-only reference — it now accepts the same StaticIconReference union (registered id, source URL, or uploaded file) as the feed icon itself.

Web app

• New feed-icon component (core-lib/feed/feed-icon) — a standalone, reusable icon renderer that resolves any IconReference (material icon name, registered icon id, source URL, or local File) to a masked background image, handling blob URL lifecycle cleanup on destroy.
• static-icon-form-field reworked to support file uploads in addition to registered/source-URL icons: onSelectIcon now reads the chosen file, a new IconRefType.File form value round-trips through the reactive form, and icon preview resolution branches on file vs. remote fetch.
• feed.model.ts: MapStyle.icon widened from SourceUrlStaticIconReference to the full StaticIconReference, and FeedPost now also carries an optional mapStyle, so admins can set a custom map marker icon at feed-creation/edit time, not just a display icon.
• Admin feed edit (admin-feed-edit-configuration, admin-feed-edit, feed-edit.model, feed-edit.service) updated to read/write the new icon reference shape and pass it through to the create/update feed request.
• Feed panel, feed panel tab, and feed item components/styles updated to render icons via the new feed-icon component instead of ad-hoc image tags.

Why this shape

• Reusing StaticIconReference (rather than a separate map-specific icon type) keeps the icon-selection UX and validation identical whether you're picking a feed icon or a map icon — one form field, one component, one code path.
• Icon resolution is pushed into a small component (feed-icon) rather than duplicated inline everywhere icons render, so blob URL cleanup and the id/sourceUrl/file/material-name branching logic lives in exactly one place.

Test plan

• service: run updated/added specs for adapters.icons.*, app.feeds, and app.icons
• web-app: run specs for feed-icon, static-icon-form-field, admin-feed-edit-configuration, feed-panel-tab, feed-item
• Manually verify migration 032 on a dev Mongo instance: collection + index created, STATIC_ICON_WRITE added to ADMIN_ROLE, and confirm down cleanly reverts the permission
• In the admin UI, create/edit a feed and set its icon via each path — registered icon, source URL, and file upload — and confirm it renders correctly in the feed panel, feed item list, and on the map