Questions about Free Space Map of PostgreSQL
This will contain some PostgreSQL internals; sorry, you asked for it.
Autovacuum doesn't run on temporary tables (because they are invisible outside your session), and at any rate, one or two updates won't trigger autovacuum. Now it is VACUUM that creates and maintains the free space map, so there is no free space map in your case. pg_freespacemap does not error out, but reports that as 0.
Lacking a free space map, PostgreSQL has to look at the individual blocks to find a block with free space in it. That leaves the riddle why the second update could find space to create a tuple in block 0.
To answer the riddle, let's discuss your statements and their effect. You can verify all this using the pageinspect extension.

the first UPDATE:
UPDATE test SET value = -1 WHERE id = 1;

That marks tuple (0,1) as updated (it sets xmax) and creates the new tuple (1,26), just as you expected.

the following query:
SELECT ctid, * FROM test WHERE value &lt;&gt; 0;

This query can get a page lock on block 0 and performs heap pruning, that is a “micro-vacuum” that frees the space occupied by dead tuples. Note that it cannot remove (0,1), because it is still referenced in an index, but line pointer (0,1) becomes a “stub” marked LP_DEAD that does not occupy any space. The space occupied by that dead tuple is freed.
Note that if you don't run that SELECT, the following UPDATE will perform heap pruning on block 0, so the effect will be the same.

the second UPDATE:
UPDATE test SET value = -1 WHERE id = 2;

Lacking a free space map, the statement looks a block 0 and notices that there is enough free space, so it performs a HOT update and puts the new tuple into block 0.