bundle: config_binding names a field that the fields table does not list, for 73 percent of its rows #890

config_binding carries the field a configuration key binds to. fields is documented as
holding "all client fields and enum constants from the IR, plus every LIBRARY field some
field_access edge reaches". A library field that no field_access reaches is therefore
absent, and config_binding references it anyway, so the join loses the row silently.

Measured on 8 Spring Boot services solved with one shared starter as --library:

So 112 of 154, 73 percent, do not resolve. A consumer joining config_binding to
fields to answer "which field does this key bind to" gets an answer for roughly a quarter
of the rows and no indication that the rest were dropped.

The 8 in neither IR are a separate, smaller question: those ids are in no all-fields.csv
on either side, so they are not explained by the library rule at all.

Why this shape rather than another

The library half is arguably working as documented: fields is deliberately not the whole
library, and a @Value field on a library type that nothing reads has no edge to justify
listing it. But config_binding is precisely the relation that says the field matters, and
it is exported. Two consistent options:

• have a config_binding row count as a reason to list the field, the same way a
  field_access edge does. That is one clause and makes the join total.
• or state on config_binding that its field column is not a foreign key into fields,
  and give the key's binding site some other resolvable identity.

The first seems better: the whole point of the relation is that something binds to that
field, so the bundle already knows it is interesting.