Partial rendering with spec change detection

[NejcS]

Replace the coarse "spec changed -> re-render the whole affected module"
behavior with functionality-level change detection. On re-render, each module's
current functional specs are diffed against the set rendered last time and
classified (added / removed / edited / moved); rendering resumes from the
earliest affected functionality, keeping the unchanged prefix instead of
rebuilding from scratch.

• Persist the rendered functionality list per module in
  .codeplain/module_metadata.json, committed per-FRID so an interrupted render
  still has an accurate baseline (storing raw FR markdown so code-variable FRs
  are not falsely flagged as edited).
• change_detection.py computes the earliest affected FRID; non-functional
  changes (definitions, impl reqs) and missing baselines fall back to a full
  re-render.
• get_render_choices offers the optimized "render from changed functionality"
  as the default, alongside full-rebuild and reset options; a functionality
  appended past the render frontier is treated as a normal continue.
• TUI defaults to the fastest (least-work) choice. Remove the obsolete --smart
  flag.

Backward compatible: builds without the new metadata fall back to a full
re-render. Covered by tests in test_change_detection.py, test_partial_rendering.py,
and test_plain_modules.py.

[NejcS]

@kaja-s I took the liberty of making some TUI design decisions. What do you think of the example screenshot above?

[dusano]

"Render from functionality 6..." > "Render from changed functionality 6..."

Mogoče to bolje skomunicira zakaj obstaja ta možnost.