feat(edit): add member modifiers, satisfy usages and requirement constraints to ApplyEdits

[devin-ai-integration]

What and why

Closes #595, #596, #597, #598, #603 and #604, and covers the authoring half of #605. ApplyEdits could add a named declaration but not the modifiers, redefinitions, parameters, results, satisfy statements or requirement constraints these models need.

message EditOperation { oneof operation { ...; AddSatisfyEdit add_satisfy = 7; AddRequirementConstraintEdit add_requirement_constraint = 8; } }
message AddMemberEdit { ...; bool is_abstract = 8; repeated string redefines = 9; bool is_default = 10; string direction = 11; }
message AddSatisfyEdit { string owner = 1; string requirement = 2; string satisfying_feature = 3; bool is_asserted = 4; bool is_negated = 5; }
message AddRequirementConstraintEdit { string owner = 1; string kind = 2; string expression = 3; string name = 4; }

• add_member gains abstract, redefines, default and direction, plus the SysML ref and return kinds. An empty name with redefines writes the :>> x shorthand; return may be unnamed when it has a type or multiplicity.
• add_satisfy writes [assert] [not] satisfy <requirement> [by <feature>];. add_requirement_constraint writes require|assume constraint [name] { <expr> }, and the expression must parse as one expression.
• Members added to a calculation, constraint or case body whose body ends in a result expression are inserted before that expression.
• Capabilities, each appended to the list: satisfy_authoring (arm 7), requirement_constraint_authoring (arm 8), and member_modifiers (new AddMemberEdit fields or the ref/return kinds). All of them also need authoring. An older service would drop the unknown fields or decode the new arms as unset, so the service and the Go, Python and Java clients refuse unless the capability is advertised.
• Python: add_member(..., abstract=False, redefines=None, default=False, direction=None), add_satisfy(owner, requirement, by=None, asserted=False, negated=False), add_requirement_constraint, add_require_constraint, add_assume_constraint, add_parameter(owner, direction, name, type=None, kind="ref"), add_return, add_succession, and typed helpers for action, state, constraint and requirement kinds. Go and Java get the matching fields and AddSatisfy/AddRequirementConstraint types.
• Stubs regenerated for Go, Python, Java, TypeScript and Rust with make proto.

Example: add_parameter("Demo::Energy", "in", "power", type="ISQ::PowerValue") then add_return("Demo::Energy", type="ISQ::EnergyValue", value="power * duration") writes in ref power : ISQ::PowerValue; and return : ISQ::EnergyValue = power * duration;.

Specification basis

Every written form is a production of the pinned SysML v2 pilot grammar. The edit layer refuses placements the grammar does not admit, even where analysis would accept them:

• abstract uses BasicDefinitionPrefix / RefPrefix, so it is refused on enum def (EnumerationDefinition has no prefix), on metadata usages, and on subject, actor, stakeholder, objective, control-node and return members. Direction follows the same rule and is written before abstract.
• default = v is FeatureValue's isDefault form. redefines applies to usages only, and definitions keep specializes.
• return is a ReturnParameterMember, admitted only by CalculationBody (calc and constraint) and CaseBody. It is refused in action, part and requirement bodies (actions use out), and at most one per body. return <expr>; is never written.
• satisfy is a SatisfyRequirementUsage, a BehaviorUsageElement, so it is admitted in packages and in any body that admits usages. It is refused in enumeration and metadata bodies and in KerML.
• require/assume constraint is a RequirementConstraintMember, admitted only in RequirementBody (requirement, concern, viewpoint, objective and satisfy).

How it was verified

• go test ./internal/check/edit/... ./internal/syntax/parser/... ./internal/frontend/grpc/... ./client/opensysml/... ./tests/grpc/... and go test -C tools ./cmd/conformance/.... New tests cover each written form, including clean reanalysis, and each refusal above. They also cover the capability gates, where the service refuses without the dedicated capability and each client refuses before sending.
• Training and pilot corpus gates with OPENSYSML_REQUIRE_TRAINING_CORPUS=1 OPENSYSML_REQUIRE_PILOT_CORPORA=1. No baseline changed.
• Python test_edit.py / test_wire_compat.py: 115 passed, 0 skipped, including live round trips against sysml-grpc.
• Java client and conformance-runner tests, and the Java conformance scenarios in 08-apply-edits.json.
• make lint, make docs-check, python3 scripts/changelog.py check, make proto-lint proto-breaking (additive only).

Checklist

• make test and make lint pass locally (make lint and the focused suites above; the full make test is left to CI)
• Tests added or updated for the change
• Documentation extended where it already covers the surface (see CONTRIBUTING.md)
• Changelog entry added as changes/unreleased/<slug>.<section>.md, not as an edit to CHANGELOG.md
• baselines regenerated and make docs-counts run if a gate count moved (no gate count moved)
• No internal work-item labels (waves, slices, F4, K5) in the body, docs, or changelog

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring