Clarify unscheduled observability follow-up work

[codeforester]

Problem

docs/observability.md now has a status callout saying basectl explain last-error, basectl report, and history cleanup are tracked but not scheduled longer-term future work. Later in the same doc, the implementation split still presents those items as numbered steps 2 through 4.

That mixed framing can make readers treat unscheduled follow-up ideas as an active roadmap sequence.

Evidence:

• The top status callout says the follow-up commands are tracked but not scheduled.
• The Implementation Split section says 2. Add basectl explain last-error, 3. Add basectl report, and 4. Extend basectl clean....

Desired outcome

The implementation split should distinguish the shipped history slice from unscheduled future work.

Scope

• Reword the implementation split so shipped work and future ideas are separated.
• Keep the status callout and section language consistent.
• Preserve the useful ordering context without implying current scheduling.

Non-goals

• Changing observability implementation scope.
• Scheduling explain last-error, report, or cleanup work.

Acceptance criteria

• The doc no longer presents unscheduled items as numbered active implementation steps.
• Future observability work is clearly labeled as unscheduled or future.
• The shipped basectl history slice remains documented accurately.

Demo impact

None.