Change Details

This code introduces new table for threads part of [messages store](https://github.com/CommE2E/comm/blob/4d82450c3188c048e666febf0137dc595c04aa1f/lib/types/message-types.js#L363). Skipping `messageIDs` as it can be computed based on message table. `start_reached` will be represented as integer `1` and `0` (but will be sent as string from js code according to the current convention) `last_navigated_to` and `last_pruned` are typed as `BIGINT`, SQLite`s concept of "type affinity" allows us to use `INTEGER` here but I believe `BIGINT` might make it clear to someone reading the code that this can not be stored in `int`. There are both approaches in the codebase so I chose the one I think is better

This code introduces new table for threads part of [messages store](https://github.com/CommE2E/comm/blob/4d82450c3188c048e666febf0137dc595c04aa1f/lib/types/message-types.js#L363). Skipping `messageIDs` as it can be computed based on message table. `start_reached` will be represented as integer `1` and `0` (but will be sent as string from js code according to the current convention) `last_navigated_to` and `last_pruned` are typed as `BIGINT`, SQLite`s concept of "type affinity" allows us to use `INTEGER` here but I believe `BIGINT` might make it clear to someone reading the code that this can not be stored in `int`. There are both approaches in the codebase so I chose the one I think is better I think we will be querying based only on `id` so an additional index will not be needed.

This code introduces new table for threads part of [messages store](https://github.com/CommE2E/comm/blob/4d82450c3188c048e666febf0137dc595c04aa1f/lib/types/message-types.js#L363). Skipping `messageIDs` as it can be computed based on message table. `start_reached` will be represented as integer `1` and `0` (but will be sent as string from js code according to the current convention) `last_navigated_to` and `last_pruned` are typed as `BIGINT`, SQLite`s concept of "type affinity" allows us to use `INTEGER` here but I believe `BIGINT` might make it clear to someone reading the code that this can not be stored in `int`. There are both approaches in the codebase so I chose the one I think is better I think we will be querying based only on `id` so an additional index will not be needed.