Attachment backend that stores nothing.

For databases that structurally never accept attachments -- barrel's own _barrel_system and _replication_tasks (see barrel_docdb.erl's ensure_system_db/0 and barrel_rep_tasks.erl's ensure_tasks_db/0), which only ever call put_local_doc/3. barrel_db_server opens an attachment store unconditionally for every database (see its init/8), and the default backend, barrel_att_store_blob, is a real RocksDB instance: even completely empty, RocksDB preallocates its WAL file (~1.1x write_buffer_size -- 64MB default -> ~70.4MB) and its MANIFEST (4MB), a fixed ~74MB floor paid once per database regardless of whether a single attachment is ever stored. Measured on a real deployment (hecate-agora, 2026-09-05): two internal databases that only ever hold a handful of small local docs were paying this floor TWICE each (once for docs, once for attachments) -- ~298MB of a 455MB total, dwarfing the actual content by two orders of magnitude.

Select this backend via att_opts => #{backend => none} on barrel_docdb:create_db/2. Every mutating call returns {error, attachments_disabled}; every read call returns the same "nothing here" result a real backend would return for a document that happens to have zero attachments (not_found from get/4, {error, not_found} from get_info/4, the accumulator unchanged from fold/5), so a caller that never writes an attachment cannot tell the difference. checkpoint/2 and destroy/2 are deliberately not exported (like barrel_att_s3_store and the test-only minimal backend): barrel_att_store degrades those to {error, unsupported} / a no-op respectively -- a none-backed database cannot be forked via timeline branching, which is fine for _barrel_system and _replication_tasks (neither is ever branched) but is a real limitation for anyone else opting into this backend.

purge_existing => true removes an attachments/ directory left by a previous backend on open. Only for databases known to never hold attachments: it deletes whatever is there.