Fix use-after-free in Connection.read_fls binding (keep_alive)

[z0mz0m]

TableReader stores a reference to its connection:

// src/include/fls/reader/table_reader.hpp
private:
    up<TableDescriptorHandle> m_table_descriptor_handle;
    Connection&               m_connection;   // <-- borrowed
    const path                m_file_path;

but the binding returns it with return_value_policy::move and no lifetime tie, so nothing keeps the Connection alive for as long as the reader. The connection can be collected while the reader is still in use, after which the reader dereferences freed memory.

This crashes the one-liner documented in README.md and used in examples/python_example.py:

pyfastlanes.connect().read_fls('data.fls').to_csv('decoded.csv')

Under lldb on an unfixed build:

EXC_BAD_ACCESS (code=1, address=0x6574617669727077)
frame #0: fastlanes::Rowgroup::Rowgroup(RowgroupDescriptorT const&, Connection const&)

The faulting address is ASCII text — freed std::string bytes being read as a pointer. It reproduces on the bundled data/example corpus, so it is not data-dependent.

py::keep_alive<0, 1>() makes the returned reader keep its Connection alive, which is the invariant the C++ type already assumes.

Verified on macOS 15 / arm64 (Apple clang 21). Three patterns that all crashed before and all pass after, each producing byte-identical output to the pattern that previously worked by accident (holding the connection in a local):

1. the README chain above (temporary connection);
2. reader = conn.read_fls(p); del conn; gc.collect(); reader.to_csv(q);
3. a reader returned from a function whose local connection went out of scope.

Note this branch alone will not compile under clang 21 without #70 (unrelated -Wnonnull failure in TypedStats); the two changes are independent in content but not in build order.

🤖 Generated with Claude Code