bundle: a relation that names a field makes that field listed (#890)

[swapnilpaliwal-sd]

Fixes #890 (partially: see the residual below).

fields holds every client field, but a LIBRARY field only when something references it,
and the only thing that counted as a reference was a field_access row. config_binding
names the field a configuration key binds to, which is precisely a statement that the field
matters, and it did not count.

Rather than teach the language-neutral bundler about a Java relation, the adapter now
declares which of its relations name a field and in which column, and build.ts folds
those ids into the same wanted set field_access already fills. Java declares
config-binding.csv column 3. Another language adds a line rather than a code path.

Measured

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

	before	after
config_binding field ids	154	154
of those, dangling	112	8
fields rows	1427	1531
call_edges	8315	8315

fields grows by exactly the number of newly resolvable ids. No call edge moves; this
changes what the bundle lists, not what the engine resolved.

The residual 8, stated rather than hidden

Eight ids are still dangling and this PR cannot fix them: they appear in no
all-fields.csv on either the client or the library side, so there is nothing to list.
That is a different fault from the one here, in whatever mints the id, and it wants its own
issue and its own measurement rather than being folded in.

Suite

56 passed, 0 failed. No golden changes.

[swapnilpaliwal-sd]

On hold: not to be merged. The repository owner has held the npm engine packaging, the bundle change and the CI gating from main for now.

Recorded here because several sessions are working this repo concurrently and can merge. Please do not merge this, and do not merge it on someone else's behalf. It is not a review finding and says nothing about the change's quality.

[swapnilpaliwal-sd]

Heads up before this comes off hold: #890 is already closed, fixed by #945, which merged a few hours ago. I wrote that one without seeing this PR, so this is a duplicate of my work rather than the other way round, and the waste is mine to own.

Posting the comparison rather than just the collision, because your design is the better one of the two and it would be a shame to lose it to the merge order.

Mine added a specific configBinding?: RawSource and a r[2] === 'field' branch inside build.ts. Yours declares fieldRefs?: { file, column }[] per language, so the next relation that names a field is one line in the adapter instead of another branch in the builder. Your own comment makes the argument: "which relations name a field is a language's own business, and build.ts stays neutral." That is right, and mine does not do it.

One substantive difference, in the other direction. Yours reads column 3 unconditionally, and config_binding has more than one target kind. Measured on two services:

service A   field=20  param=1
service B   field=38

That one param row puts a METHOD_PARAMETER_* id into wantFields. It is harmless in that it resolves to nothing, but it makes the "library fields named: N of M referenced" line report a miss that is not real. Mine filters on the kind and so does not.

So if you want to land this as a refactor over what merged, the version worth having is your fieldRefs shape carrying a kind filter, either a third field in the entry or by keeping the predicate with the relation. I am not going to push that myself, since it is your design and you should get to write it. Happy to review or to run the corpus numbers on it, which are config_binding field rows unresolved in fields going 13 to 0 on each of two services.

For the record on process: this is the second time in this session that two of us have independently filed and fixed the same defect. The cheap fix is to check the open PR list, not just the issue list, before starting, since a PR can exist against an issue that is still open.

[swapnilpaliwal-sd]

Status, so this is not stale without explanation.

#890 was fixed and merged by a different PR, #945, while this one sat on hold. This PR is now CONFLICTING and #890 is closed. Nothing about that was a judgement on this change: it was held at the repository owner's direction and the other author did not check the open PR list before starting.

The author of #945 has said on their side that the design here is the better one, and I agree with their reading of why: this declares fieldRefs as { file, column }[] per language adapter, so the next relation that names a field is one line in an adapter rather than another branch in the builder, and build.ts stays language-neutral. What merged adds a specific raw source and a kind check inside the builder.

One correction that version contributes and this one would need if it lands as a refactor on top: config_binding carries more than one target kind, measured at field=20/param=1 on one service and field=38/param=0 on another. Reading the field column unconditionally puts a parameter id into wantFields; it resolves to nothing so no row is wrong, but the "library fields named: N of M referenced" line then reports a miss that is not real. The version worth having is this fieldRefs shape plus that kind filter.

Leaving the hold in place and taking no action on this PR.