bug: make file-section concurrency detection resistant to same-second rewrites

[codeforester]

Parent: #214

Problem

base_file_update_file_section promises optimistic concurrency safety: a concurrent target change should leave the newer target untouched and return status 6. The current fingerprint in lib/bash/file/lib_file.sh uses device, inode, size, mtime, and ctime, but the portable stat formats record timestamps only to whole-second precision.

A same-size rewrite of the same inode within one second therefore produces the same fingerprint, and the later atomic commit overwrites the concurrent writer.

Evidence

Reviewed at commit d064f426681f0e340ff4990ba0c9830084a5fe12.

A focused reproduction created a three-byte target, captured its fingerprint, rewrote it with different three-byte content in the same second, then committed a staged update:

before=16777231:223367623:3:1788247652:1788247652
after=16777231:223367623:3:1788247652:1788247652
status=0
content=new

The documented concurrency contract expected status 6 and the concurrent content to remain intact.

Impact

Ordinary concurrent writers can be silently lost despite the public no-overwrite guarantee. This is a correctness and data-loss risk for configuration-file updates.

Acceptance criteria

• Detect same-size, same-second rewrites without relying only on whole-second metadata.
• Leave the newer target untouched and return status 6 for the reproduced race.
• Preserve symlink-target behavior, file mode preservation, atomic replacement, and Bash 4.2/macOS/Linux portability.
• Add a deterministic adversarial regression for a same-inode, same-size rewrite.
• Run the focused file BATS suite and ./tests/validate.sh.

Review validation

The existing full validation gate passes (587 BATS tests), confirming this edge case is not covered today.