feat: add native search results vertical slice

[fgirolami29]

Cosa introduce

• registra il parent nativo Divi 5 codecorn/search-results, mostrato nel Builder come CC Search Results;
• registra il child configurativo codecorn/search-result-type, mostrato come CC Result Type;
• popola il post type del child con una select dinamica derivata dai post type pubblici registrati da WordPress;
• usa child ripetibili come regole per badge, label, colore, immagine, excerpt, data e CTA;
• deriva una query privata dal contesto della ricerca WordPress corrente senza sostituire o mutare $wp_query;
• fa governare al parent post type, risultati per pagina, layout e paginazione sia in AJAX sia nella navigazione classica;
• usa una WP_Query isolata per preview, pagine normali e shortcode;
• aggiunge renderer condiviso e accessibile per riepilogo, form, risultati, paginazione e stato vuoto;
• mantiene [cc_divi5_search_results] come adapter opzionale e non come implementazione primaria;
• mantiene README e CHANGELOG sincronizzati con il comportamento incluso.

Correzione query e paginazione

La prima implementazione di source=current restituiva direttamente i post già risolti dalla query globale. Di conseguenza il limite del sito — nel collaudo Barbagia, 3 risultati — ignorava Results per page sia nella paginazione normale sia in AJAX.

Ora il resolver:

1. legge gli argomenti e il termine della ricerca corrente;
2. non modifica la query globale;
3. rimuove offset e limiti incompatibili;
4. applica i post type configurati nei child;
5. applica posts_per_page e pagina corrente del parent;
6. esegue una WP_Query privata;
7. espone il filtro cc_d5sr_current_query_args.

Valori vuoti o non validi di Results per page tornano a 10. Colonne e quantità di risultati sono indipendenti: una grid a 5 colonne può mostrare il numero di elementi configurato, non il limite globale del sito.

Presentazione frontend

Il parent espone:

• risultato totale visibile o nascosto;
• form di ricerca completo visibile o nascosto sopra il primo risultato;
• preset Editorial grid;
• preset Compact vertical list per elementi orizzontali bassi;
• preset Classic image card, con titolo immediatamente sotto l'immagine;
• colonne responsive indipendenti per desktop, tablet e telefono, con default 3 / 2 / 1;
• paginazione AJAX attivabile o disattivabile.

La presentazione è ora separata in:

• assets/css/search-results.css per struttura e comportamento;
• assets/css/search-results-theme.css per pannello, form, profondità card, accent dei tipi, compact list e paginazione.

Gli asset frontend e Visual Builder usano versione plugin + filemtime, così i deploy iterativi della stessa 0.1.0 non restano bloccati da cache browser o proxy.

La precedente paginazione era composta da normali link WordPress. Il runtime applica progressive enhancement: recupera la pagina reale, individua la stessa istanza del modulo, sostituisce soltanto il suo output, aggiorna la URL, ripristina focus e scroll e torna alla navigazione classica in caso di errore.

Le stringhe frontend predefinite sono italiane (Cerca, conteggio risultati, stato vuoto, Precedente, Successiva, Vedi risultato). I child già salvati con il vecchio valore predefinito esatto View result vengono renderizzati come Vedi risultato; le CTA personalizzate non vengono alterate.

Contratto architetturale

• nessun query_posts();
• nessuna sostituzione o mutazione della query globale;
• nessun CPT o metadato Barbagia hardcoded;
• il parent governa query, layout e navigazione;
• i child governano le regole dei tipi di risultato;
• shortcode e modulo condividono gli stessi servizi PHP;
• AJAX non introduce un endpoint query alternativo.

Baseline già verificata

Prima dell'ultimo fix page-size/theme è stato eseguito localmente su macOS:

• npm run check: OK;
• TypeScript tsc --noEmit: OK;
• parsing dei due module.json: OK;
• npm run build: OK;
• bundle Visual Builder, CSS e modules-json/: OK;
• PHP lint su tutti i file: OK.

Webpack terminava con due sole deprecation warning della legacy JS API di sass-loader; non erano errori. Le segnalazioni audit dei pacchetti divi-types* non devono essere corrette con npm audit fix --force.

Il nuovo contratto query è stato inoltre verificato con uno smoke test PHP isolato: una query corrente con limite 3 viene derivata con limite 5, pagina 2, post type configurati e offset rimosso.

Toolchain, packaging e deploy

• .npmrc applica engine-strict=true e legacy-peer-deps=true;
• composer.lock e package-lock.json sono inclusi;
• reset-install preserva package-lock.json e usa npm ci;
• npm run check valida TypeScript, metadata JSON e runtime JavaScript frontend;
• .reference/ è esclusa da Git;
• gli output webpack sono ignorati nel sorgente ma inclusi nel pacchetto runtime;
• composer package genera archivio runtime, manifest e SHA-256;
• composer deploy:check esegue packaging e verifiche senza SSH;
• composer deploy supporta WordPress host/Docker con backup e rollback;
• composer deploy:barbagia usa il Compose file assoluto /home/fgirolami/docker/barbagiamusei/compose.yaml e risolve dinamicamente il service wp_cron.

Gate corrente

L'ultimo fix query/theme deve ora superare:

1. npm ci;
2. npm run check;
3. npm run build;
4. composer check:syntax;
5. composer deploy:barbagia:check;
6. deploy reale su docker02;
7. verifica che Results per page valga ugualmente con AJAX ON e OFF;
8. verifica grid a 5 colonne con page size 5 e 10;
9. verifica dei tre preset ai breakpoint Divi >980, 768–980, <=767;
10. ricomposizione finale della cronologia tecnica in un unico commit revisionabile.

La PR resta draft e non viene mergiata prima del collaudo e della supervisione del codice.