Decoupling form builder app from end user forms

## Context

**The structure aspect needs a major overhaul.**
We are at a point now where tackling any tech debt is a significant undertaking. We keep building on an underlying framework that is messy and cobbled together. It's hard to rebuild the structure while adding to it.

We also need to figure out how to balance ongoing tech debt
→ NextJS, React, always get new things in frameworks

## What this might entail

- Separated prisma, styles
- Figure out if monorepo, separate repo
- Could be single sprint → decoupling provides different avenue to address debt in the future
- SLA impacts? Potential complications – ex: previewing, need to think this through
- Moving styles – used on SSO repo – decoupling things as we go, ex: hcaptcha package
- Prototyping platform products – around NextJS

## Performance wins

- Front-facing public forms could end up as its own app
- Separate it from the building experience and responses
- Breaking out that piece from "layouts" to stand alone in the code
- Consider where to wrap context with server and client components

## Value of breaking it out

- Definitive split for styles, form fields
- App/builder can go down when front-facing form stay up
- Detangled rather than bundled (heavier) has scaling advantages
- Better integrate GCDS with form output without interfering with form builder
- Translations (to maintain states, locales in URLs / strings)
- Consider impact of a future integration with CanadaLogin

No files, tests, or concrete entry point are identified. Start by mapping how the builder, public forms, responses, layouts, styles, and Prisma are currently connected, then define the app or repository boundary and verify that public forms remain available independently of the builder.

Written by the indexing model from the issue text.