Improving block file change detection

[jtyr]

Summary

Fixes two related issues with editor macro scripts and the block file.

Problem 1: Block file not saved before macro execution

edit_block_process_cmd() runs a numbered macro script that may reference %b (the block file). However, the selected block is not written to the block file before the script runs, so %b points to a stale or nonexistent file.

The fix is to save the selected block to EDIT_HOME_BLOCK_FILE at the start of edit_block_process_cmd(), before calling edit_user_menu().

Problem 2: Block file modification missed due to second-precision timestamps

edit_user_menu() detects whether a macro script modified the block file by comparing st_size and st_mtime before and after execution. Scripts that rearrange bytes without changing file size (e.g., word-wrap replacing spaces with newlines) and complete within the same second produce identical st_size and st_mtime, causing a false negative - the editor does not reload the modified block.

The fix is to use nanosecond-precision st_mtim (via HAVE_STRUCT_STAT_ST_MTIM, already detected by configure) instead of second-precision st_mtime. Falls back to st_mtime on platforms without nanosecond support.

Test plan

• Select a block, run a macro that transforms it (e.g., sort, word-wrap) - the result should be inserted back into the editor
• Run a macro that produces identical file size but different content - the change should be detected
• Build on a platform without st_mtim - should compile and fall back to second-precision comparison

[mc-worker]

Please add a detailed info to the commit message.

[jtyr]

@mc-worker Please could you clarify why the commit message needs more detail? The PR description already contains the full explanation of the changes. Is there a reason the commit message needs to duplicate that information?

[ossilator]

PR descriptions are the equivalent of cover letters in git-send-email, or the part below the '---' line of individual commit messages seen by git-am. also, they are proprietary to the hosting platform.
iow, they are worthless for the committed history of a project that intends to remain sovereign.

[mc-worker]

@mc-worker Please could you clarify why the commit message needs more detail?

Your few-words commit messages in #5070 and #5071 tells almost nothing people who will look to the git history about what bugs and how are fixed. There are no references to corresponding PRs. The first commit message in a branch should respect the following pattern:

Ticket #ABCD: brief info.

More or less detail info.

The PR description already contains the full explanation of the changes.

PR description and git commit message are independent entities. In my point of view, the git history should be self-sufficient to offline work with and should not require to address to online resources.

Is there a reason the commit message needs to duplicate that information?