No.

The cid column is a zero-based numbering of the output rows of the pragma that indicates the order in which the rows are output from the query that implements the pragma. It is NOT an attribute of the field (=row) itself, nor does it necessarily reflect the order in which the fields appeared in the CREATE TABLE statement or the order in which the fields are stored within a record. It MAY be so sometimes (or even mostly), but SQLite docs expressly exclude any guarantee thereof.

You cannot determine the order of table records within a B-tree table leaf page. You cannot even determine if two given records are in the same B-tree table leaf page. This should already be apparent from the description of the file format. https://sqlite.org/fileformat2.html

If all you ever do to a table (that was created without an explicit alias for the internal rowid) is INSERT and SELECT, then table records will tend to be stored in order of rowid. The greater the difference between rowids, the more likely is is that there will be at least one "page break" between them.

As soon as you start UPDATEing (which could change their size, depending on the values of the fields) or DELETEing (which creates "holes" in the leaf pages, that may or may not be reused) rows, SQLite may need to move records within (or even between) leaf pages, which may lead to out-of-order storage of rows.

Apart from curiosity, there is no reason to be concerned with the internal storage order of a conceptually unordered set, aka table. Indeed it is highly dangerous to rely on any implicit ordering, as this order may change without warning, which is the reason one is required to provide an ORDER BY clause if one desires a specfic order in which result rows are to be returned.