Independant Flags for PR Review Environment

In the existing PR Review model the feature flags settings are reused from the existing Staging environment. This can cause issues when new feature flags need to be tested on PR Review branches as they cannot be turned on/off independently of the Staging Environment.

Existing solution (best viewed as GitHub issue):

```mermaid
flowchart TD
A[Staging Image Startup] -->|Check Flags| B{Flags Exist}
F[PR Review App] --> |read / write| E
G[Staging App] --> |read / write| E
B --> |yes| C[Update new / removed Flags]
B --> |no| D[Create Flags\n with default values ]
C --> E[Redis 'flags' contained in set]
D --> E

```

A solution needs to be developed to allow PR Review environments to run in isolation of the feature flag settings.
There is an existing Environment variable in PR Review containers that identify them as such. The `REVIEW_ENV` variable is only set in the PR Review image.

Acceptance Criteria:
- [ ] The solution must not rely on code changes that can be accidentally merged into `develop` and overwrite staging / production settings
- [ ] The solution must clean up after itself if feature flag artifacts are created during it's lifetime
- [ ] The solution should be transparent to the developer working on new feature flags. No new process other then modifying the existing flag-initialization json should be implemented.

Start by locating the PR Review container startup, the existing flag-initialization JSON, and the code that uses REVIEW_ENV to access the Redis flags set. Trace how staging initializes and cleans up feature-flag artifacts, then define an isolated lifecycle that meets the acceptance criteria without requiring a new developer process.

Written by the indexing model from the issue text.