feat: features 025-032 - favoritos, contatos, trabalhe-conosco, area-cliente, navbar, hero-light-dark, performance-homepage

- feat(025): favoritos locais com FavoritesContext, HeartButton, PublicFavoritesPage
- feat(026): central de contatos admin (leads/contatos unificados)
- feat(027): configuração da página de contato via admin
- feat(028): trabalhe conosco - candidaturas com upload e admin
- feat(029): UX área do cliente - visitas, comparação, perfil
- feat(030): navbar UX - menu mobile, ThemeToggle, useFavorites
- feat(031): hero light/dark - imagens separadas por tema, upload, preview, seed
- feat(032): performance homepage - Promise.all parallel fetches, sessionStorage cache,
  preload hero image, loading=lazy nos cards, useInView hook, will-change carrossel,
  keyframes em index.css, AgentsCarousel e HomeScrollScene via props
- fix: light mode HomeScrollScene - gradiente, cores de texto, scroll hint

migrations: g1h2i3j4k5l6 (source em leads), h1i2j3k4l5m6 (contact_config),
            i1j2k3l4m5n6 (job_applications), j2k3l4m5n6o7 (hero theme images)

specs/024-filtro-busca-avancada/contracts/api-catalog-enhancements.md

@@ -1,7 +1,7 @@
 # API Catalog Enhancements — Contrato de Interface
 
-**Feature**: `024-filtro-busca-avancada`  
-**Tipo de mudança**: Adição de campo somente-leitura em endpoints existentes (backward-compatible)  
+**Feature**: `024-filtro-busca-avancada`
+**Tipo de mudança**: Adição de campo somente-leitura em endpoints existentes (backward-compatible)
 **Versão da API**: `/api/v1` (sem mudança de versão — campo adicional não quebra clientes existentes)
 
 ---

specs/024-filtro-busca-avancada/plan.md

@@ -1,6 +1,6 @@
 # Implementation Plan: Filtro de Busca Avançada — FilterSidebar
 
-**Branch**: `024-filtro-busca-avancada` | **Date**: 2026-04-20 | **Spec**: [spec.md](./spec.md)  
+**Branch**: `024-filtro-busca-avancada` | **Date**: 2026-04-20 | **Spec**: [spec.md](./spec.md)
 **Input**: Feature specification from `/specs/024-filtro-busca-avancada/spec.md`
 
 ---
@@ -13,14 +13,14 @@ Enriquecer os endpoints de catálogo existentes com o campo `property_count` (CO
 
 ## Technical Context
 
-**Language/Version**: Python 3.12 (backend) · TypeScript 5.5 (frontend)  
-**Primary Dependencies**: Flask 3.x, SQLAlchemy 2.x, Pydantic v2 (backend) · React 18, Tailwind CSS 3.4, Axios (frontend)  
-**Storage**: PostgreSQL 16 — sem novas tabelas ou migrations (`property_count` é calculado via `func.count` + `outerjoin` no ORM, não persistido)  
-**Testing**: pytest (backend — testes de integração nos endpoints enriquecidos)  
-**Target Platform**: Browser SPA (desktop); Linux server via Docker  
-**Project Type**: web-service (Flask REST API) + SPA (React)  
-**Performance Goals**: busca cross-categoria < 50 ms (processamento local, NFR-001); endpoints de catálogo < 300 ms p95 (COUNT em tabelas pequenas, < 5 k registros)  
-**Constraints**: sem nova dependência npm ou Python; sem rotas novas; filtros mobile fora de escopo; estado de expansão das seções não persistido em `localStorage` (NFR per spec)  
+**Language/Version**: Python 3.12 (backend) · TypeScript 5.5 (frontend)
+**Primary Dependencies**: Flask 3.x, SQLAlchemy 2.x, Pydantic v2 (backend) · React 18, Tailwind CSS 3.4, Axios (frontend)
+**Storage**: PostgreSQL 16 — sem novas tabelas ou migrations (`property_count` é calculado via `func.count` + `outerjoin` no ORM, não persistido)
+**Testing**: pytest (backend — testes de integração nos endpoints enriquecidos)
+**Target Platform**: Browser SPA (desktop); Linux server via Docker
+**Project Type**: web-service (Flask REST API) + SPA (React)
+**Performance Goals**: busca cross-categoria < 50 ms (processamento local, NFR-001); endpoints de catálogo < 300 ms p95 (COUNT em tabelas pequenas, < 5 k registros)
+**Constraints**: sem nova dependência npm ou Python; sem rotas novas; filtros mobile fora de escopo; estado de expansão das seções não persistido em `localStorage` (NFR per spec)
 **Scale/Scope**: 3 schemas Pydantic editados, 2 rotas Flask editadas, 1 componente React reformulado (~600 linhas → ~800 linhas), 2 arquivos de tipos TypeScript editados
 
 ---
@@ -200,8 +200,8 @@ Section recebe `open={openSections[key]}` + `onToggle={() => toggleSection(key)}
 
 **Rationale**: Evita migration desnecessária (Constitution IV). `property_count` é dado de leitura; persistir seria denormalização sem benefício real dado o volume (< 5 k imóveis). Subquery em tabelas pequenas é negligenciável em performance.
 
-**Alternativas descartadas**:  
-- SQLAlchemy `column_property` com correlated subquery: mais limpo no ORM mas adiciona complexidade ao modelo sem ganho real (usado uma vez).  
+**Alternativas descartadas**:
+- SQLAlchemy `column_property` com correlated subquery: mais limpo no ORM mas adiciona complexidade ao modelo sem ganho real (usado uma vez).
 - Coluna persistida com trigger: over-engineering (Constitution VI); requer migration + lógica de atualização.
 
 **Impacto na serialização**: Os routes handlers passam a construir dicts manualmente para City/Neighborhood. Para PropertyType (hierárquico), o `property_count` é injetado nos subtypes após serialização com `model_dump() | {'property_count': count_map.get(sub.id, 0)}`.