[TASK] Frontend — Erli connection credentials checkbox + offer wizard category/parameters steps

[norbert-kulus-blockydevs]

Part of #1381. Depends on #1383.

Problem / Context

Once the backend (#1382, #1383) can expose CategoryBrowser/CategoryParametersReader for a configured Erli connection, the frontend needs: (1) a way for the operator to enter the Allegro app credentials on the Erli connection, and (2) an Allegro-style category + parameters flow in the Erli single-offer wizard, replacing today's plain-text Category ID field. Design is pre-approved — see the mockup:

UI mockup: https://claude.ai/code/artifact/5008010f-2c02-4813-8531-30b1e776f26f

Proposed Solution

Full detail: docs/plans/implementation-plan-erli-allegro-category-catalog.md § Sub-task 3 (Phase 3).

1. ErliCredentialsPanel (apps/web/src/plugins/erli/components/erli-credentials-panel.tsx): add a checkbox ("Browse Allegro categories when creating Erli offers") gating a disclosure panel with Client ID / Client Secret fields (masked, show/hide toggle), per the mockup. Merge into the existing useUpdateConnectionCredentialsMutation call alongside apiKey; omit both new fields (not empty strings) when unchecked.
2. Category step in erli-create-offer-wizard.tsx: when connection.config.allegroCategoryAccessEnabled is true, render CategoryPicker (reuse Allegro's component) instead of the plain <Input> around line 413-420; otherwise keep today's field plus the fallback hint from the mockup, linking to the connection's edit page. Note (correction post-[TASK] Integration — Erli adapter capability wiring + credentials/config validators for Allegro category access #1383): connection.supportedCapabilities is a static, per-adapterKey manifest value — it does NOT vary per connection instance and cannot be used for this gate (see ADR-031 "Correction", docs/architecture/adrs/031-erli-allegro-category-catalog-via-client-credentials.md). Use the new allegroCategoryAccessEnabled config flag (already added to ErliConnectionConfig in [TASK] Integration — Erli adapter capability wiring + credentials/config validators for Allegro category access #1383/PR feat(erli): wire per-connection Allegro category-catalog capability + credential/config validation #1399) instead.
3. Category-parameters step: add parameters to erli-create-offer.schema.ts/ErliCreateOfferValues; new step (only when capability active + category selected) rendering category-parameters-step.tsx fed by the existing useCategoryParametersQuery; write to overrides.parameters on submit (backend merge logic already handles this, no BE change needed).
4. Stepper labels: ERLI_STEP_LABELS becomes capability-conditional (['Variant','Offer details','Category','Category parameters','Review'] vs today's 3-step array) — mirror AllegroCreateOfferWizard.tsx's SetupStepper usage.
5. needsProductParameters flag (currently hardcoded false around line 190): make capability-conditional.

Classification

Type: Frontend
Layer: Interface
File(s): apps/web/src/plugins/erli/components/erli-credentials-panel.tsx, apps/web/src/features/listings/components/erli/erli-create-offer-wizard.tsx, apps/web/src/features/listings/components/erli/erli-create-offer.schema.ts

Dependencies

• Depends on [TASK] Integration — Erli adapter capability wiring + credentials/config validators for Allegro category access #1383 (backend capability + validators must exist first).
• Part of epic [EPIC] Erli: category/parameter browsing from Allegro's catalog without a required Allegro connection #1381. Last sub-task — a single final PR with the full epic's functionality follows this.

Assumptions

• No new query hook needed — reuses useCategoryParametersQuery and CategoryPicker verbatim from the Allegro wizard.
• Client-side "both or neither" validation for the two new credential fields (Zod), backstopped by the server-side shape validator from [TASK] Integration — Erli adapter capability wiring + credentials/config validators for Allegro category access #1383.

Acceptance Criteria

• Checkbox reveals/hides the Allegro credential fields in the Erli connection form, matching the approved mockup
• Submitting with only one of Client ID / Client Secret filled is blocked client-side before hitting the API
• Erli offer wizard renders the category tree + parameters steps when the connection has Allegro access configured, and today's plain-text fallback + hint otherwise
• A required category parameter left empty blocks submit (parity with the Allegro wizard)
• Submitted Erli offers with parameters filled via the wizard reach the existing ErliOfferManagerAdapter.buildExternalAttributes wire mapping unchanged (no BE regression)
• Unit tests added/extended: erli-credentials-panel.test.tsx, erli-create-offer-wizard.test.tsx
• pnpm --filter @openlinker/web lint && type-check && test green
• No architecture boundary violations (feature/plugin dependency direction respected per docs/frontend-architecture.md)

Write-path responsibility for allegroCategoryAccessEnabled (added post-#1383 review)

The backend code path that saves allegroClientId/allegroClientSecret (whichever endpoint/mutation this issue implements or extends for the checkbox-reveal credentials panel) MUST, in the same request, set config.allegroCategoryAccessEnabled = true when both credential fields are being set to non-empty values, and false when either is cleared. This keeps the flag from silently drifting out of sync with the actual credential state. Add a test asserting this atomicity in both directions (enable and disable).