Build Cucumber + HTTP mock test harness for registry-loader with initial test coverage

[jordanpadams]

Summary

Implement the test harness recommended in the evaluation task (#139), using an HTTP mock framework and Cucumber BDD, and deliver an initial set of test cases that provide meaningful confidence in the core harvest and manager workflows.

The goal is not exhaustive coverage but a solid starting foundation: enough scenarios to catch regressions in the most critical paths, written in Cucumber feature files so they serve as living documentation and can be extended incrementally as new bugs are identified and fixed.

Acceptance Criteria

• Shared HTTP mock harness in place, configurable to return realistic OpenSearch bulk API responses including: success, partial failure, 409 conflict (duplicate LIDVID), throttling/OCU errors, and network-level failures
• Cucumber feature files and step definitions in place under a dedicated test module or package (not mixed with existing tt/ integration tests)
• Initial scenario coverage includes at minimum:
  • Successful harvest of a single valid PDS4 label → product written to registry
  • Harvest of a label that already exists → SKIPPED outcome logged, no duplicate write
  • Harvest of a label that OpenSearch rejects with a non-conflict error → FAILED outcome logged with reason
  • Bulk request that receives a throttling/OCU response → retry behavior exercised
  • Harvest of an oversized or malformed file → IGNORED outcome logged
• Tests pass in CI without requiring Docker or a live OpenSearch instance
• Each scenario maps traceably to a behavior described in the harvest/manager acceptance criteria

Dependencies

Blocked by #139 (framework evaluation and selection).

---

For Internal Dev Team To Complete

⚙️ Engineering Details

🎉 Integration & Test

🤖 Generated with Claude Code