0 -       undefined, normally an uninitialized page and indicates a bad page pointer elsewhere;

     1 -  Database header page

     2 - Page inventory page

     3 - Transaction inventory page

     4 - Pointer page

     5 - Data page

     6 - Index root page - contains information about each index on the table, one per table

     7 - Index (B-tree) page

     8 - Blob data page

     9 -       Generator pages

The second problem (CCH_precedence: block marked.  file: cch.cpp line: 4390) is more concerning - I don't remember having read a bug about it.  CCH is the cache handler.  A "mark" is the sign that a page is about to be changed.   When Firebird is forced to write a page either as part of a commit or to free space in the cache, it must write out any pages that the page depends on first.  That's a little obscure.  Suppose that the page you're about to write has a record with a back version, and the back version is on a different page.  To keep the database consistent, the page with the back version must be on disk before the page that includes a record that points to the back version.  Firebird keeps a list of precedence relationships and CCH goes through them before writing a page.  I think the error means that someone is currently writing  to a page that's on the precedence list.  That should never happen.  It's interesting that the problem occurred during an alter index operation.  However, the database should be fine on disk and usable after you restart Firebird.  Page marks are entirely in memory.  It's quite possible that I missed a bug report and this problem was fixed in a later version.

The third problem is two records in a referencing table lack mates in the referenced table, despite a referential constraint.  I have no idea how that happened, but it should be reasonably easy to fix in your database.

The first problem is what I would call a physical  corruption - the internal structure of the database is corrupt.  The second is an in-memory   corruption - the disk database is OK, but the in-memory version is damaged.  The third is logical corruption - the database is physically intact, but does not conform to the data rules..