materials: plasticity builds its own elastic tangent

[petlenz]

4 of 5. Stacked on the Drucker-Prager collapse. Three commits, two arguments.

The elastic dependency was dishonest

All three plasticity classes read the stiffness from an elastic_source's tangent. That looked like flexibility and was not: the closed forms require isotropic C_e — it is what makes C_e : N = 2G N and N : C_e : N = 3G true. rk_plasticity assumed it twice, also through effective_modulus(G) = 3G. A caller wiring an anisotropic tangent would have got silently wrong answers.

And harmful

It pulled a linear_elasticity into every plasticity graph, whose own stress output is not merely unused there but wrong — it is C : eps with eps_p ignored, so once yielding starts it is not the stress of anything:

step	alpha	j2::stress	elastic::stress	error
40	0.0094	106.25	107.69	+1.4%
120	0.1094	306.25	323.08	+5.5%
200	0.2094	506.25	538.46	+6.4%

A postprocessor logging elastic::stress from a plasticity graph gets that, under a name that reads as authoritative.

All three now build C_e from moduli they hold. j2_plasticity and rk_plasticity gain a K parameter; drucker_prager_plasticity needs nothing new, since K_bulk and G were already required for the cone. A plasticity graph no longer contains an elastic material at all.

linear_elasticity is untouched and keeps its users — for a genuinely elastic model C : eps is the answer, and isotropic_damage consumes both its stress and its tangent legitimately.

Also: the redundant stress contraction

The return map contracted twice — trial stress, then returned stress. The second is sig_trial - dl (C_e : N), no contraction needed. This is the one step that is not bit-identical: algebraically equal but ordered differently, so it agrees to ~1 ULP. Kept as its own commit for that reason.

Performance, for the whole 4-PR chain

Two binaries built from the actual commits, run interleaved so each pair sees the same machine state; 15 pairs; speedup computed per pair:

	old (median)	new (median)	paired speedup	range
J2	1466.2 ns/step	211.5	7.00x	5.54-8.84x
Drucker-Prager	1176.3 ns/step	652.4	1.79x	1.58-1.90x

The range is the honest figure — the same binary measured 1171-2253 ns across runs, so any single-run comparison on this machine is worth about one significant digit.

J2 gains more because it also sheds machinery it never used. DP keeps the non-associative structure and the apex branch and gains only the arithmetic, which is the correct outcome: the generality DP pays for is generality DP uses.

+80/-41 across 7 files.

[petlenz]

Critical review. The argument holds — I re-ran the divergence measurement and the elastic stress really does drift to +6.4 % — but the change introduces a naming collision, and the two materials it touches disagree with each other.

K now means three things in one document

Before this PR, j2_plasticity took no bulk modulus: it read the tangent from an elastic material. It takes one now, and lands next to a hardening material that already uses that letter for something else:

{"type": "linear_isotropic_hardening", "name": "hardening", "K": 1000.0}   <- hardening modulus, H = K k
{"type": "j2_plasticity",              "name": "j2",        "K": 166.67}   <- BULK modulus
{"type": "drucker_prager_plasticity",  "name": "dp",  "K_bulk": 166.67}   <- bulk, spelled differently

Three parameters called K or K_bulk, two distinct physical quantities, and the two plasticity materials this stack created spell the same quantity differently. A deck author reading "K": 1000.0 next to "K": 166.67 has no way to see that one is a hardening slope and the other a bulk modulus.

That is squarely the failure mode this stack has been removing elsewhere: a value that is wrong-but-plausible and reads as authoritative. Transposing those two numbers gives a model that builds, runs, and yields — at the wrong stress.

j2_plasticity and j2_rk_plasticity should take K_bulk, matching Drucker-Prager. Two-line change each plus the test fixtures, and it makes the collision impossible rather than merely documented.

(linear_isotropic_hardening's K is pre-existing and arguably wants to be H or hardening_modulus, but renaming it touches an unrelated material and its tests — worth its own issue rather than this PR.)

The correctness argument re-verified

step  40  alpha 0.0094   j2 106.25   elastic 107.69   +1.4%
step 120  alpha 0.1094   j2 306.25   elastic 323.08   +5.5%
step 200  alpha 0.2094   j2 506.25   elastic 538.46   +6.4%

And the isotropy claim checks out: effective_modulus(G) = 3G already required it, so this makes an existing assumption explicit rather than adding one. The three-commit split is right — the ~1 ULP step is isolated so a reviewer can see exactly which change costs exactness.

Related, from the #40 review

The same document that can now set K and G still cannot choose the integrator: the solver type is compile-time fixed, and j2_rk_plasticity's tableau is a raw pointer the JSON reader cannot convert. Detail on #40.