## At a glance

A model names its storage exactly as it is written:

```prisma
model UserProfile {
  id    Int    @id
  email String
}
```

That reads and writes the table `"UserProfile"`. A different name is
stated with `@@map`, and changing the name renames the existing table
rather than creating a new one:

```ts
override get operations() {
  return [
    ...this.renameTable({ table: 'userProfile', to: 'UserProfile' }),
  ];
}
```

Both behaviours have shipped. This closes out the project that delivered
them.

## Changes

- **ADR 258** records the decision: storage names are verbatim on every
authoring surface, a rename is an operation the author states, the
planner cannot infer one, and the `MIGRATION.TABLE_NAME_CASE_CHANGED`
check is transitional. Its alternatives section keeps the three rejected
designs, including the planner hint that remains the intended direction.
- **The Data Contract subsystem document** gains a "Storage names"
section stating the rule, next to the existing section on planner hints.
- **The Migration System subsystem document** records `this.renameTable`
as a stated operation and the planner's refusal, where it lists the core
operations.
- **`projects/psl-verbatim-table-names/` is deleted.** Project
directories are transient; what outlives them is in `docs/`.

## Why

The rule lives in two subsystem documents because both readers need it:
someone authoring a contract needs to know that nothing transforms case,
and someone reading the migration system needs to know that a
storage-name change is a rename the author states. The ADR carries the
reasoning once, and both documents link it.

Refs: TML-3420

Agent: figaro-38


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Clarified that model and field names map to table, collection, and
column names as written, unless `@@map` or `@map` specifies otherwise.
* Documented that changing a model’s storage name requires an explicit
migration. Table renames also update eligible objects named by the
planner; objects changed by the migration or explicitly named retain
their database names.
* Explained that migration planning rejects certain drop-and-create
changes where names differ only by the case of the first letter, and
provides options for resolving them.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Signed-off-by: willbot <w.a.madden+machine@gmail.com>
Signed-off-by: Will Madden <madden@prisma.io>