Remove the task processor's unused cursor

ProcessorActions::set_cursor and the cursors map that backs it are carried by the task processor but used by nobody.

Nothing sets one

Every implementor of nextActions we have ignores the argument and leaves set_cursor as None:

• examples/task-processor/src/service.rs:84 — async fn next_actions(&self, _cursor: Option<String>, _now: Timestamp)
• pm-app's pm-oracle/src/service.rs — async fn next_actions(&self, _cursor: Option<String>, now: Timestamp), and it never assigns set_cursor

So TaskProcessor::cursors stays empty in every deployment, and the cursor: argument in the GraphQL query is always null.

Why it is worth removing rather than leaving inert

The cursor is not free: it is a piece of per-application state whose semantics are unspecified. The doc says only

An optional cursor for the task processor to store and pass to the application upon the next query for actions.

which does not say whether an application may treat it as a high-water mark. It may not: the processor assumes the opposite, since process_group documents that "tasks are assumed idempotent, so whatever is left unsubmitted is recomputed by the next call to nextActions". An application that read the doc and implemented "everything up to this cursor has been handed out, I will not return it again" would silently lose work whenever a task group failed after the cursor advanced.

An unused feature that invites an incorrect implementation is worth deleting while no one depends on it.

Surface

Small and confined to the framework:

• linera-base/src/task_processor.rs:28-30 — the set_cursor field and its doc.
• linera-service/src/task_processor.rs — the cursors: BTreeMap<ApplicationId, String> field (:59, :89), its retain in apply_update (:164), the read and the write around the query (:213, :230-231), and the cursor parameter of query_actions (:373).
• The query string itself (:377-378): nextActions(cursor: …, now: …) becomes nextActions(now: …).

Note

That last point makes it an ABI change for applications: every service implementing nextActions has to drop the parameter, so examples/task-processor and pm-app's pm-oracle need matching changes, and the two have to land in the right order relative to each other. That is the whole cost — nothing reads the value, so there is no behaviour to preserve.