fixed-spec-chart-template

Spec chart exports still let an admin replace the Excel template under
Settings → Spec Chart and edit the cell mappings that say where form values
go. That has to go. As I put it:

> rn i dont know how we are possibly knowing where to place inputted values from forms into a random excel they upload - so the spec chart is just fixed at our standard so we know how to wire it up

Make the bundled standard workbook, `web/templates/spec-chart-v7.01.xlsx`,
with its fixed cell mapping, the only spec chart template:

- Remove custom template upload, reset and cell-mapping editing, both from
  Settings → Spec Chart and from the API. The spec design API must reject a
  request to save or reset a template; saving brand logos through it keeps
  working.
- Every generated workbook (the download and the copy written to Azure on
  save) uses the bundled template. Ignore any template override already
  stored in the database: it no longer affects exports or saves, and the API
  no longer returns it.
- Settings → Spec Chart becomes a read-only page whose download returns
  exactly the stored bundled file.

The file we store should be the one we show, and it should be the true
template we populate, not the original input workbook with its hidden tabs.
Clean it up so it contains only the two customer-facing sheets, **Model
Spec** and **Full Spec**: no Form, Grading, Lists or other helper sheets,
nothing left that refers to them, and no sample values or placeholder
pictures. Keep its layout, labels, styling, artwork and print settings; the
labels customers see in an export stay in English, as they are today.

Exports then write the chart's values directly into those two sheets, at
the existing mapped cells. Full Spec's graded size rows keep Excel formulas
(written with their results), but they compute from the measurements on
Model Spec and the increments shown in Full Spec's grade row, so editing a
Model Spec measurement or a grade-row increment in Excel regrades the sheet.

## Environment

PostgreSQL on localhost:5432 and the local database endpoint the app's
driver uses are running when you start, and the dev env files point at the
dev database.