feat(core): introduce internal database schema abstraction layer

[dev-queiroz]

Summary

Introduce a database-agnostic schema abstraction layer inside Forge to unify how persistence models are represented before being transformed into specific generators (e.g., Prisma, SQL, future ORMs).

This is a foundational architectural layer for Forge’s evolution into a multi-backend compiler.

---

Motivation

Currently, Forge maps:

• Contracts → OpenAPI
• Contracts → NestJS
• Contracts → Prisma (planned)

However, each generator currently interprets contracts independently.

This leads to:

• duplicated mapping logic
• inconsistent type handling
• difficulty scaling to new backends

---

Goals

Introduce an internal intermediate representation:

Forge Contract → DB Schema Layer → Generators (Prisma, SQL, etc.)

---

Requirements

1. Define DB Schema IR (Intermediate Representation)

Example structure:

DatabaseModel {
  name: string
  fields: DatabaseField[]
}

DatabaseField {
  name: string
  type: DBType
  isPrimary?: boolean
  isOptional?: boolean
}

---

2. Centralize type mapping

All type conversion must happen in this layer:

Forge → DB Schema IR

No generator should interpret Forge types directly.

---

3. Support multiple generators

This layer must support:

• Prisma Generator
• Future SQL Generator
• Future Mongo Generator

---

4. Decouple architecture

Generators must depend only on DB Schema IR, not on Forge AST or semantic model.

---

Constraints

• Do not break existing OpenAPI or NestJS generators
• Do not introduce runtime behavior changes
• Keep backward compatibility

---

Acceptance Criteria

• DB Schema IR exists and is used internally
• Prisma generator consumes this layer
• NestJS/OpenAPI remain unaffected
• Type mapping is centralized
• Architecture is decoupled and extensible