feat(inertia): link server page props to the client that reads them

[ferrine]

Branch: ferrine:feat/inertia-prop-boundary → main
Size: 9 files, +1038 · Tests: inertia-prop-boundary.test.ts (29),
inertia-props.test.ts (13)

Why

Inertia (Laravel, Rails, Phoenix) renders a page by handing a server-side prop
map to a client component. There is no REST schema and no GraphQL document:
the contract is that map, and it is written twice — once as the server map,
once as a client destructure or type. Nothing in either half references the
other, so the boundary is invisible to a graph built from calls and imports, and
three ordinary questions have no answer:

• this prop is emitted — is it read anywhere? (a dead prop costs a query and
  payload on every render)
• this prop is read — is it still emitted? (renders as undefined, silently)
• I am renaming this prop — what else must change in the same commit?

Worse, when the server camelizes its keys the two halves do not even share a
spelling: the server emits user_display_name, the client reads
userDisplayName, so grepping either finds exactly one side. That is what makes
it a resolver problem rather than something search can answer.

What changed

A framework resolver plus a synthesis pass. Each prop a server hands to a page
becomes a symbol, linked to the code in the page component that actually reads
it.

No configuration and no global state. Rather than read the adapter's
camelize setting out of project config — which would have to be discovered once
and then carried into per-file extraction — a prop carries both candidate
spellings and the consumer scan records which one matched. That works unchanged
for Laravel and Rails (verbatim keys) and for Phoenix with camelize_props: true, and it cannot silently mis-link if a project's setting is not what we
assumed. Phoenix.Naming.camelize/2 has several divergences from a naive
snake→camel (acronyms, digits, preserve_case); those are implemented and
tested individually.

A prop counts as used only when a real function or value reads it. A type
or interface that merely declares the field does not count — that is what keeps
a never-rendered prop visible instead of appearing used by its own type
declaration. The distinction is per symbol, not per file, so a module exporting
both payload types and runtime helpers is treated correctly as both. Test files
are deliberately still counted: a rendered-page test is sometimes the only thing
that reads a field.

Two detection fixes folded in, both found on a real Phoenix app

• Detection read manifests at the repository root only. Inertia spans a
  server and a client, so the app that uses it is frequently not the root of
  the repo — a mix.exs beside its own assets/, or a package.json under a
  client workspace, with the root holding only tooling. Reading the root alone
  meant the whole feature stayed silently switched off on exactly the layout
  Inertia projects tend to have. Manifests are now looked for anywhere in the
  index, by filename, capped so a repo that does not use Inertia does not pay.
• The Phoenix pattern required the connection as a positional argument.
  Idiomatic Elixir pipes it — conn |> render_inertia("Page", %{...}) — so the
  call carries only the page and the props and matched nothing. The leading
  argument is now optional, with quotes excluded from it so the page name is not
  mistaken for one.

Known limit (stated so it isn't a surprise)

Extraction reads a literal map at the render call. A project that assembles
props anywhere else — builder functions that return maps, or a wrapper that
assigns keys one at a time before rendering — has no literal map adjacent to any
render call, and nothing is extracted. That is a real gap rather than a bug in
this PR; closing it needs either a project-supplied hint or interprocedural data
flow, and neither belongs here.

Notes for review

A no-op on any repo without an Inertia adapter in a manifest.