Give the Next List one name, in code and in copy

[capo-the-ai-bot]

User Story

As a user, I want one name for the list of things I could do next, so the drawer and the planning step stop appearing to be two different lists.

Scope

Local naming only — no storage, no wire.

• Rename providers, screens and copy from "Next Actions" to Next. The List holds Outcomes; "Next Action" stays as the role-label for the singular current Action of a row.
• Resolve the two user-facing names: the drawer renders "Next Actions" while the Daily Planning step renders "Up Next". The divergence is currently deliberate — the step's pool is energy-filtered and net of what is already picked, so one shared name would show two different counts under one label. Either give the filtered pool its own domain term, or record the divergence with that reason in the relevant term's definition.
• Rename Intent.maybe and its copy to the CONTEXT term Someday/Maybe.

Acceptance Criteria

• No provider, screen or string calls the List "Next Actions" where the List is meant
• Exactly one user-facing name per domain List, or a recorded reason for the divergence
• Intent.maybe and its copy carry the CONTEXT term
• flutter analyze clean and the full suite green
• The two List-naming Flagged ambiguities are deleted from CONTEXT.md

Related

Part of #715. Independent of the Todo and Task renames.

[capo-the-ai-bot]

Parked pending the planned server rework.

The audit and the scope stand — the divergences, their counts, and the split between local renames and wire renames do not change. What is unresolved is the migration mechanism, and it is entangled with the server:

• Renaming ops in place preserves history and entity identity, but the signature covers the body and each op names its predecessor's hash, so it is a re-sign plus a chain rebuild. The server's log is append-only with uq_ops_workspace_author_seq and no delete route, so there is nowhere to put the rewritten chain today.
• A fresh Workspace under a v2 uuid5 derivation avoids all of that and needs no server change, but leaves the old log behind rather than renaming it.

Which is right depends on what the server rework does to op storage, so choosing now would be choosing blind. Picking this up alongside that work is the cheaper order.

Nothing here is time-sensitive: the divergence is a readability trap, not a defect, and it gets marginally more expensive only as more devices enrol.