[dev-ant]

Item sitemap requests exceeded the frontend deadline because eligibility filtering and sorting could scan the remaining catalog even for a small page. This change reads at most 1,000 ordered identities at a time, evaluates the shared eligibility predicate within that candidate range, and continues until limit+1 eligible items or the catalog end. The public item order, cursor, eligibility and hasNext contract stay unchanged.

V34 adds the matching (name, top_category, sub_category) index while retaining the primary key. Application version is 1.0.10.

Validation:

• Synthetic MySQL 8 with 10,000 rows: identity windows use the covering index; eligibility uses approximately 1,000-row ranges instead of full catalog scans. Baseline first query was about31ms; one identity window was0.23ms and its eligibility query3.17ms. These are synthetic samples, not production latency guarantees.
• Dense first/keyset pages exactly match the prior predicate query; sparse/fully ineligible windows, same-name categories, retained statistics, continuation and catalog end are covered.
• The migration is reapplied in a test and its index column order is checked.
• Standard Gradle verify, workflow-contract tests and mocked Elasticsearch rollout script checks pass.

Each candidate window adds two queries; a sparse tail can require multiple windows. Production query timing and index build duration remain to be observed during the authorized rollout.