feat(start-sdk,start-os)!: let a service run an action that takes input

[helix-a]

What changes

A service can run an action that takes input — its own, or another service's that access admits. Before this, both failed:

• The SDK's Action.run validates against the form getInput built under the same event id (prevInputSpec[effects.eventId]).
• On the service path, effects.action.getInput and effects.action.run are separate effect calls, and each runs under a fresh procedure_id. That id is #[serde(default)], skipped in the TypeScript type, and a new random Guid per call.
• So every run threw getActionInput has not been called for EventID ….

The fix uses the handshake the user's CLI already has (start-cli package action run --event-id):

• start-core (Rust): the effect's RunActionParams takes an optional event_id. When present, the run executes under it instead of the per-call id. The EffectsRunActionParams binding and the start-container action run man page are regenerated.
• start-core (TS): Effects.action.run gains eventId?. Effects.action.getInput gains prefill?, which the generated GetActionInputParams and StartOS already accepted but the hand-written type omitted.
• sdk.action.run (breaking, in the unreleased 3.0.0):
  • input is now a function from the opened form (spec, plus the value from the action's prefill function) to the input.
  • The helper calls getInput, applies the function, and runs under that form's eventId.
  • It gains packageId, which was commented out, so it could only target the service's own actions, and prefill.
  • A plain input value is no longer accepted: it could not answer a form.
  • An action without input runs without opening one.
• Docs: the packaging book's actions page gains "Running Another Service's Action", and the access section points at it. The 3.0.0 changelog gets one ### Changed entry.

Why

Start9Labs/tor-startos#39 makes Tor's Add/Delete Onion Service access: 'public' so a service can manage its own addresses. Start9Labs/bitcoin-core-startos#309 is the first consumer: after retiring the port its StartOS 0.3.5 version bound, Bitcoin re-attaches that version's peer .onion to its current binding. Nothing in the tree ran an action with input from a service before, which is how the event-id gap went unnoticed. #4045 notes the path was not exercised on a box.

For the reviewer to decide

startosTypeValidation.test.ts checks one direction only: each generated params type must be assignable to the Effects parameter. A binding field missing from Effects still passes, which is how getInput's prefill went unnoticed. I have not made the check two-way here, since it may surface other effects that already differ.

Verification

• cargo check -p start-core and make start-core-format-check pass.
• make start-core-ts-bindings and make manpages change only EffectsRunActionParams.ts and start-container-action-run.1.
• start-core: tsc passes, and make test passes 17 suites. The new runAction.test.ts drives a real Action through effects that give each call a fresh event id, as StartOS does. It checks three things: the helper answers the form it opened; a run naming no opened form is still refused; and an action without input skips the form.
• start-sdk: make bundle, make check and make test (131 tests) pass. container-runtime's npm run check passes against the rebuilt bundle.
• Prettier 3.8.3, the repo pin, passes on every changed file. The packaging book builds with mdBook v0.5.2.
• Not exercised yet on a box. I am testing it through Bitcoin → Tor on a VM built from this branch.