[QRD-7899] feat(configuration-webhook): add affiliate config topic

[javigutierrezfer]

What is the goal?

Add a reusable "affiliate" configuration topic to integration-core's ConfigurationWebhookAPI, so every seQura payment plugin can receive its affiliate (Prime) configuration — enabled, Offer ID, Security Token — through the existing signed config-push mechanism, with no manual UI. Part of the autoconfiguration-first approach (Option A) of epic QRD-7897.

References

• Issue: QRD-7899 (epic QRD-7897)
• Related pull-requests: woocommerce-sequra #163 (consumer plugin, QRD-7898)

How is it being implemented?

Mirrors the simplest existing topic, AdvancedSettings, as an end-to-end vertical slice:

• Domain (Domain/Affiliate): AffiliateSettings model (isEnabled, offerId, securityToken), AffiliateSettingsRepositoryInterface, and AffiliateSettingsService — the reusable read service plugins use to obtain the resolved config.
• DataAccess (DataAccess/Affiliate): AffiliateSettings entity (indexed by storeId) + repository.
• ConfigurationWebhookAPI: SaveAffiliateSettingsRequest, AffiliateSettingsResponse, and Get/Save topic handlers.
• Wiring: get-affiliate-settings / save-affiliate-settings added to the Topics enum (and ALL_TOPICS), and registered in BootstrapComponent (repository, service, topics, handler services).

Signature validation and the topic dispatch are reused as-is; no new signing logic is introduced.

Caveats

• The exact payload field names (isEnabled / offerId / securityToken) are the proposed config contract and may be adjusted once the cross-team contract is confirmed (decision D5 in the epic); the structure won't change.
• Table creation is the responsibility of each host plugin (it registers a repository for the new entity, as with the other settings entities). integration-core only registers the entity for tests.

Does it affect (changes or update) any sensitive data?

The Security Token is a credential-like value. It is persisted per store like the other settings and only delivered through the existing signed config-push. It is not logged.

How is it tested?

Automatic tests (PHPUnit):

• New AffiliateSettings entity test, repository test (get/set/update/delete + multistore isolation), and service test.
• 3 end-to-end cases in ConfigurationWebhookAPITest: save persists, get returns the persisted config, get with no settings returns empty.

Full suite: 819 tests OK (16 new), 0 regressions. PHPCS (PSR12) clean. PHPStan level 6: no errors.

How is it going to be deployed?

Standard deployment (library release/tag, consumed by the payment plugins).

🤖 Generated with Claude Code