Dev: Write up database core tables and schema

[naman0r]

ℹ️ Issue

Closes #3

📝 Description

Adds the BHO database schema. The doc describes each table, and the migration creates the tables in Postgres.

1. docs/database-schema.md lists every table and column, with the spreadsheet cell each column comes from.
2. db/migrations/0001_init_schema.ts is a Kysely migration. It creates users, stations, imports, daily_observations, hourly_observations, scheduled_observations, daily_records, and audit_log, and adds station 19737-02. Deleting a day also deletes its hourly and scheduled rows. down drops everything.
3. A trigger on the four weather tables writes one audit_log row per insert, update, or delete. To record who made a change, the writer calls set_config('app.user_id', ..., true) and set_config('app.import_id', ..., true) in its transaction.
4. db/types.ts has the Kysely type for each table.
5. db/client.ts has createDb(), which returns date columns as 'YYYY-MM-DD' strings. By default pg returns a Date at local midnight, so 2026-07-01 is 04:00Z on a laptop in Eastern time and 00:00Z in Lambda.
6. Adds kysely@^0.27.0 to the root package.json, the same version the Lambdas use.

Only audit_log.action is an enum. Values that may change, like imports.status, are text.

✔️ Verification

Ran the migration against Postgres 16 in Docker with Kysely's Migrator and FileMigrationProvider pointed at db/migrations. Until #11 adds yarn db:migrate, that is the way to run it. Checked that:

• up, down, and up again succeed, and down leaves no tables, type, or function behind.
• Deleting a day deletes its hourly and scheduled rows.
• Inserts, an update, and the cascaded deletes each wrote an audit_log row with the row's key and the user.
• With TZ=America/New_York, createDb() reads 2026-07-01 back as the string "2026-07-01".

🏕️ (Optional) Future Work / Notes

• hourly_observations.mountainVis (1@1.5) stays text. The client says it is mountain number @ visibility on a 1-3 scale. Once the weather group says which number is which mountain, split it into mountainId and mountainVisibility with a mountains table.
• On 4 days in July the peak gust has two times (28 WNW @ 1631E, 1651E), and July 19 has two directions. peakGustDir and peakGustTime hold one value each.
• daily_observations.remarks reads G47-G49, but notes also appear in G50-G54 on some days.
• importId is required on daily_observations and daily_records, which assumes only uploads write weather data. If staff can edit values in the app, it needs to be nullable.
• Re-uploading a month logs every row as an update, even when only importId changed.

[Rayna-Yu]

Looks good to me!

Non-blocking: One thing to note though, is I think pg parses a Postgres date at the server's local midnight. So that would be UTC in Lambda and Eastern for our laptops. This shouldn't be an issue because we are planning on running everything in Lambdas anyways, but something that we may need to be careful about.

[CharlesTChapman]

Looks good to me. All entities and fields match sample data well and relational structure seems logical.