[Blocked by #518] feat(header): make Resource Center secondary nav author-editable

[sdmcraft]

Summary

• The /blog/* "Resource center" secondary nav now reads its categories/links from an authored content/blog-nav.html fragment (a nav-menu block, same pattern as the primary nav's content/nav.html), instead of the hardcoded SECONDARY_NAV_ITEMS constant in header.js. Marketing can now edit these links in DA without a code change.
• The hardcoded list is kept as a fallback, rendered only if the fragment is missing/malformed — same resilience pattern as the primary nav's NAV fallback, so the header always paints.
• A new secondary-nav page-metadata key (default /blog-nav) lets a page override the fragment path, mirroring the existing nav metadata convention.

Content update

• Added a new DA source, /blog-nav (single nav-menu block, 5 categories), link-for-link identical to what's live today on erp.intuit.com/blog's Resource Center nav (verified via live DOM inspection). Already created and previewed — see https://main--intuit-erp--aemsites.aem.page/blog-nav.

Bugs fixed along the way

• Duplicate DOM ids: nav-menu.js generated flyout ids as flyout-<row-index> with no cross-instance uniqueness. Once the primary and secondary nav are both rendered from nav-menu.js-decorated fragments on the same /blog/* page, this produced colliding ids, breaking aria-controls/aria-labelledby uniqueness. Fixed with a module-level instance counter, prefixing ids as flyout-<instance>-<row>.
• Unguarded new URL(): computing the nav/secondary-nav metadata path could throw synchronously on a malformed value; since that computation now sits inside a Promise.all in decorate(), an uncaught throw there would abort the entire header render (not just the nav path in question). Wrapped in resolveNavPath() with a safe fallback, applied to both nav paths.
• Deduplicated fetchNavMainHTML/fetchSecondaryNavItemsHTML (were near-identical) into a shared fetchNavMenuBlock(), and added console.warn on both the "fetch threw" and "fragment missing/malformed" failure paths so content QA has a signal instead of a silent fallback.

Known follow-up (not in this PR)

• blocks/footer/footer.js has the same unguarded new URL(footerMeta, ...) pattern this PR fixed for header.js. Pre-existing, unrelated to this issue — worth a separate follow-up.

Test plan

• npm run lint clean
• npx vitest run — same 11 pre-existing failures as main, unrelated to these files, no regressions
• Verified locally and on branch preview: /blog renders the secondary nav from authored content, flyouts open/close correctly, no duplicate ids, fallback verified by temporarily removing the fragment
• Verified homepage/non-blog pages unaffected
• Preview: https://blognav--intuit-erp--aemsites.aem.page/blog

Fixes #69

[aem-code-sync]

Hello, I'm the AEM Code Sync Bot and I will run some actions to deploy your branch and validate page speed.
In case there are problems, just click a checkbox below to rerun the respective action.

• Re-run all PSI checks
• Re-run failed PSI checks
• Re-sync branch

Commits

• d98f0bb ✅ (latest)

[aem-code-sync]

	Page	Scores	Audits
📱	/blog
🖥️	/blog

[sdmcraft]

The PSI check failure here (mobile LCP on `/blog`) is very likely unrelated to this PR — traced it to the pre-existing, already-tracked #518, which root-causes the LCP to a lazy-loaded, hotlinked `erp.intuit.com` card thumbnail in `blog-cards.js` (unrelated to header/nav-menu). Confirmed via performance trace: header.js's fragment fetches (including the new `/blog-nav`) run in parallel with the LCP image's own load chain, not blocking it, and run-to-run LCP variance on unmodified `main` (2.9s–6.1s) already exceeds any delta seen here.

Suggested next step: resolve #518 first, then re-check PSI on this branch.

[sdmcraft]

Blocker fix proposed: #655