Rename the "status" identifier to "state" across all runtime entities (instance, token, work item, incident)

The term "status" is overloaded and, on the runtime entities, semantically wrong: an instance, a token, a work item and an incident each expose a machine status that is really an inner state (a token is active/parked/consumed; an instance running/completed; a work item open/claimed/done; an incident open/resolved). This issue renames that identifier to state across all four entities, so the code names the concept correctly and consistently.

Follow-up to #3611306, which renamed the instance lifecycle label from "Status" to "State" (freeing "Status" for the workflow-authored status) but kept the machine identifiers to avoid a breaking change. This completes the rename at the identifier level.

Scope (all four runtime entities)

• Base field status to state on ProcessInstance, Token, WorkItem and Incident: four base-field renames (storage plus active-config resync). Existing rows carry stored values, so each needs a data migration, not just a code change.
• Constants STATUS_* to STATE_* on each interface (ProcessInstanceInterface, TokenInterface, WorkItemInterface, IncidentInterface). The stored values (running, parked, open and so on) stay unchanged.
• Accessors getStatus()/setStatus() to getState()/setState(), and WorkItem's getStatusLabel() to getStateLabel().
• Instance token machine keys [orchestra:status] and [orchestra:status-label] to [orchestra:state] and [orchestra:state-label].
• Storage-schema index names, entity queries, Views field/filter configs, and the admin filters and lists.

Cross-repo

yoyaku consumes this API (instance and token status), so it must be updated in lockstep (a matching yoyaku issue). Any other consumer is affected too.

Why separate from #3611306

#3611306 delivers the user-visible label split and the State and Status Views fields with no breaking change. This is a set of base-field renames (config resync plus storage migration on four tables) and a public API change spanning repositories, so it warrants its own review and migration plan.