generate-frontend.js: header entity named like a known secondary-tab key duplicates its own Table/Form import

[Gremiger]

Bug

resolveSecondaryTabDefs()'s backward-compat fallback (used whenever a window
declares no window.secondaryTabs in decisions.json) matches a hardcoded list
of known tab keys (orderTax, invoiceTax, basicDiscounts, paymentPlan,
accounting, landedCost, reversedInvoices) against the contract's entity
names. The final result is only filtered against detailEntity, never against
headerEntity.

If a window's own primary/header entity happens to be named one of those keys
(e.g. accounting) and declares no secondaryTabs, the fallback re-includes
the header entity as a "secondary tab", re-emitting its own Table/Form
imports a second time in the generated Page.jsx. This produces:

SyntaxError: Identifier 'AccountingTable' has already been declared.

which fails Babel parsing — a blocker in the Schema Forge Quality Gate
(imports/parse checks) and would break the generated build at runtime.

Repro

Any single-entity window whose primaryEntity (and no detailEntity) is
named accounting (or any other key in the hardcoded list) with no
window.secondaryTabs declared. Found via the end-year-close spec added in
etendo_schema_forge#868 (ETP-4478).

Fix

cli/src/generate-frontend.js — resolveSecondaryTabDefs(): exclude
headerEntity (not just detailEntity) from the final filter before slicing
to the first 4 secondary tab defs. Regression test added in
cli/test/generate-frontend.test.js (resolveSecondaryTabDefs headerEntity collision (ETP-4482)).

Fixed on feature/ETP-4482 off epic/ETP-3504.