Fixes for SQLite version 007 migration

[brandur]

I tried running the River test suite on an alternate River repo I had,
and ran into this failure:

--- FAIL: Example_libSQL (0.01s)
panic: error applying version 007 [UP]: SQL logic error: Cannot add a column with non-constant default (1) [recovered, repanicked]

goroutine 1 [running]:
testing.(*InternalExample).processRunResult(0x27a61a107bd8, {0x0, 0x0}, 0x1009add28?, 0x0, {0x1018f4c80, 0x27a61a8d7960})
        /opt/homebrew/Cellar/go/1.26.1/libexec/src/testing/example.go:92 +0x4b0
testing.runExample.func2()
        /opt/homebrew/Cellar/go/1.26.1/libexec/src/testing/run_example.go:59 +0xdc
panic({0x1018f4c80?, 0x27a61a8d7960?})
        /opt/homebrew/Cellar/go/1.26.1/libexec/src/runtime/panic.go:860 +0x12c
github.com/riverqueue/river/riverdriver/riverdrivertest_test.Example_libSQL()
        /Users/brandur/Documents/projects/alt_river/riverdriver/riverdrivertest/example_libsql_test.go:30 +0x368
testing.runExample({{0x1011457d5, 0xe}, 0x1019fdb28, {0x101158290, 0x23}, 0x0})
        /opt/homebrew/Cellar/go/1.26.1/libexec/src/testing/run_example.go:63 +0x1f8
testing.runExamples(0x101a16038?, {0x101acd420, 0x2, 0x37?})
        /opt/homebrew/Cellar/go/1.26.1/libexec/src/testing/example.go:41 +0xec
testing.(*M).Run(0x27a618bbba40)
        /opt/homebrew/Cellar/go/1.26.1/libexec/src/testing/testing.go:2445 +0x60c
main.main()
        _testmain.go:80 +0x80
FAIL    github.com/riverqueue/river/riverdriver/riverdrivertest 2.364s
FAIL

It turns out that it was surfacing a problem in the new SQLite version
007 migration that only manifests when existing river_queue data was
present. It was balking at adding a new column in an ALTER TABLE with
a non-constant default value like CURRENT_TIMESTAMP.

This turns out to be a relatively easy fix because elsewhere in the
migration we were already rewriting that able anyway (usually in SQLite
you have to rewrite tables on DDL changes, but there's a few tricks
under some circumstances you can use not to), so all we have to do is
move the DEFAULT up to that rewrite statement.

I asked Codex if it could find any similar bugs in the migration, and it
identified one more similar one that could happen if you migration down
from 007 to 006 and have river_job data present. Similarly, we wrap
this one up into an already existing table rewrite in the migration.

Added a couple test cases to verify these changes work as expected.