Closes ENG-1035

Description Of Changes

Adds back missing data-testid attributes in FidesJS components for development Docker builds. The issue occurred because FidesJS builds were stripping test IDs even in dev environments, making some e2e Privacy Center tests break.

The solution adds an IS_TEST build argument that preserves test IDs only for dev builds while maintaining the current behavior (stripped test IDs) for all production builds.

Code Changes

• Dockerfile: Added ARG IS_TEST=false and ENV IS_TEST=$IS_TEST to the frontend build stage to accept and propagate the test flag
• docker_nox.py: Modified app_info_map to conditionally pass --build-arg IS_TEST=true for fides and the privacy center when tag == "dev"

Steps to Confirm

1. To test the Dockerfile change, you can locally build the image and pass it the IS_TEST argument. So something like: docker build --build-arg IS_TEST=true --target=prod_pc -t test-privacy-center-with-testids .
2. As far as the nox file change, you can test most of it by adding the following before the last line

session.log(f"Generated buildx command: {' '.join(buildx_command)}")
return

That will show you the build command being run. For extra thoroughness, you could take the command, remove the ''--push" flag, and then build it locally as well.

I'll also pull down the dev image when it gets published after this is merged so I can double check.

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required