Guard a wrapped read with a flag on the record

[nz]

Fourth of the stack, based on #54.

The recursion guard cost more than the work it guarded

The guard kept its bookkeeping in a thread-local hash, which meant building an [object_id, name] key on every wrapped attribute read: an allocation and two hash operations to protect against a case that almost never happens, on the hot path of every converted model.

Measured with rake benchmark:optional_reader, which this PR adds, same harness both sides:

shape	before	after
plain reader	116 ns, 0 allocs	112 ns, 0 allocs
wrapped	511 ns (4.4x), 2 allocs	232 ns (2.1x), 1 alloc
wrapping with no guard at all	212 ns (1.8x), 1 alloc	204 ns (1.9x), 1 alloc

The guard cost roughly 299 ns against the ~95 ns the wrapping itself costs. A flag on the record needs no key, so it now costs about 30 ns and the only allocation per read is the Option being returned.

This is the same class of problem as #16, an order of magnitude smaller: that guard used caller.length and made a read ~40x slower.

What holds it in place

A test differences two batches of reads so the per-read allocation is measured without the harness counting itself: 100 marginal allocations with the flag, 200 with the thread-local hash. The existing recursion cases still hold — a genuine re-entry raises at first re-entry naming the reader, and a legitimately deep stack does not.

benchmark/optional_reader.rb stays in the tree with a rake task, so the next change here can be compared rather than argued about. It reports three shapes: the plain reader as the floor, the wrapped reader, and wrapping with no guard at all as the ceiling on what a guard may cost.

The tradeoff, stated plainly

A flag on the record cannot tell genuine recursion apart from the same record instance being read by two threads at once. An ActiveRecord instance shared that way is already outside what ActiveRecord supports, and actual recursion through a wrapped reader is rare — so the error message now names the second possibility and points at the issue tracker, rather than insisting the reader re-entered itself:

LoopyAuthor#bio re-entered itself; something beneath this reader reads it again.
If this read was not recursive, the record may have been read from two threads at once,
which this guard cannot tell apart. Please report that at
https://github.com/omc/errgonomic/issues

Also here

Rubocop stops applying the size cops under benchmark/, and Naming/PredicatePrefix no longer reads the has_one macro override as a predicate. Note that a per-cop Exclude replaces the department-level Metrics: Exclude:, so ClassLength, BlockLength and MethodLength each repeat the paths.

Testing

rake — 31 tests, 82 assertions, and 118 doctests, all passing. Rubocop reports the same 7 pre-existing offenses as main.