fix(sdk): findById answers null for an absent id, as documented (#6420)

[delchev]

Closes #6420.

The mismatch

JavaRepository.findById(Object id) documents "the entity, or null if not found", but delegated to a store method that threw IllegalArgumentException instead. The documented null never happened, so every findById + null-guard was dead code — and the null-guard is the shape the docs teach, so it is everywhere:

• a client-Java controller looking a record up by a path param never reached its own 404; the request came back 500,
• Posting.java.template guards if (source == null || ...) return; — a source row deleted between the event and the handler threw instead of skipping,
• the generated schedules-notify job resolves a cross-model recipient with entity.Customer == null ? null : new CustomerRepository().findById(entity.Customer) — a dangling FK killed the whole job run instead of skipping one row.

The fix

Honour the documented contract: findById answers null when there is no such row.

That is the coherent half of the pair, not just the cheap one. An absent id is an ordinary outcome of a lookup, and what it means belongs to the caller — a 404 at a controller boundary, a skip in an event handler. findOne(id) stays the Optional sibling for a caller that wants to chain its own failure (findOne(id).orElseThrow(...) carrying its own status), and the generated REST controllers already read single records through exactly that. Every generated template — the events glue and the DAO/REST templates alike — was written against the documented contract, so this makes their guards live rather than requiring ~40 call sites to be rewritten around a throw the name never suggested. It also keeps the client-Java model's Spring-Boot idiom intact, where a find* that may not find is the norm and a throwing lookup carries a different name.

No template, generator or platform caller depended on the throw: JavaEntityStore.findById was its only site.

Verification

New JavaRepositoryFindByIdIT (HTTP-only, ~30 s) deploys a client-Java project — entity, @Repository extends JavaRepository<T>, and a controller in the documented shape (findById + null-guard → 404) — and asserts:

• an unknown id → the controller's own 404, on both the null-returning and the Optional variant,
• a stored record → 200 with its data (the null is about absence, not about the whole lookup).

Confirmed to fail without the fix: with the throw restored, the unknown-id request is a 500 and the test errors on that assertion.

Also green: data-store-java + engine-java unit tests (101), and JavaEngineIT, JavaComponentIT, JavaTemplateIT, JavaEntityLobColumnIT, NumberingSdkIT.

🤖 Generated with Claude Code