Rebuild a feasible Sprint forecast

Repair sprint-plan.json. Select a forecast that supports both validated-address and accessible-confirmation. Include each selected item's prerequisites unless already complete, and allocate all its build and quality work to members with the relevant skill without exceeding anyone's available hours. Work may be split across qualified members. You may select either delivery route and may reserve extra hours when capacity permits. Keep the team's estimates and availability as planning facts, outside the editable plan. Availability after events and other commitments: Maya has 18 hours (build); Noah has 12 hours (build and quality); Rae has 6 hours (quality). Nothing is already complete. Backlog facts: schema: 6 build + 2 quality hours; no prerequisite; an enabling item with no customer outcome on its own. address-api: 10 build + 4 quality hours; requires schema; supports validated-address. confirmation: 8 build + 4 quality hours; requires address-api; supports accessible-confirmation. hosted-address: 12 build + 6 quality hours; requires privacy-review; supports both customer outcomes. privacy-review: 2 quality hours; no prerequisite; enables the hosted service and has no customer outcome on its own. promo-banner: 10 build + 2 quality hours; no prerequisite; supports promotional-messaging, which is outside this Sprint Goal. The team's Definition of Done includes these quality activities; build hours cannot replace them. Use forecast as a list of item IDs and allocations as records with item, skill, member and hours. Skills are build or quality; member IDs are maya, noah and rae. Combine repeated allocations for the same item/skill/member. Hours and allocation records are this scenario's planning technique, not a Scrum requirement. A feasible forecast remains subject to inspection and adaptation during the Sprint.