Add polling to fetch experiment configs from GrowthBook

What?

• Add experiments table to db/init.sql to hold GrowthBook-originated (and TK-registered for an interim period) experiments
• Update Experiment model to only include fields needed to build the TK API response
• Add service/growthBookClient.js: authenticated HTTP client with configurable retry logic
• Add service/growthBookPoller.js: polls GrowthBook on startup and at a configurable interval, updates the experiment configuration cache on each successful fetch
• Add service/experimentStitcher.js: merges TK and GrowthBook experiment lists; GrowthBook wins on slug conflict;
• Add service/experimentConfigurationService.js: minimal stubs to validate/adapt the GrowthBook API response (to be expanded in T421803 and T421804), loads TK experiments from the DB, stitches both sources (to be elaborated in T421808), and inserts the result into the experiments_cache table
• Map GrowthBook custom fields event_stream, contextual_attributes) to Experiment model fields
• Wire poller into app.js and service/serviceRegistry.js
• Add growthbook config block to config.dev.yaml and config.prod.yaml; inject GROWTHBOOK_API_KEY from environment in config/configuration.js
• Add feature flag run_poller in growthbook config block to gate polling on staging and production
• Add unit tests for all new components

Why?

• Experiments defined in GrowthBook need to be visible alongside TK-registered experiments so that Enrollment Authorities receive a unified, authoritative list of experiments regardless of which platform an experiment owner used to configure their experiment

Testing Instructions:

• In config.local.yaml, add your api key in the growthbook config block
• Run make run-dev in local dev environment
• Check the experiments table in your local docker database to see both TK-originated and GB-originated experiments

Bug: T421800
Bug: T421805
Bug: T421808