DBF: physical count refresh correctness and error forwarding

[bedipritpal]

Stage 2: physical record-count refresh correctness and error forwarding, on upstream d64064d after PR186.

• Ordinary DBF physical refresh uses complete record bodies rather than max(header,file-size), so stale high headers do not resurrect rows after shrink/empty and stale low headers do not hide completed appends.
• Refresh failures reach local AdsGetRecordCount and server GetRecordCount replies; local output is left untouched on failure. NTX/ADT/cache wrappers forward the result.
• Full-table encryption retains fixed-length counting; partial encryption retains its separate header-count path. Neither format changes.

One commit, 12 files (+223/-28), with focused tests and scope doc. No OPENADS_FRESH_COUNTS switch, client count-cache policy, ordered-position optimization, Harbour core, protocol, security-policy or CI/workflow changes. Cache hits still follow the existing policy; this fixes the result when a physical refresh occurs.

Credit/provenance: Pritpal Bedi's cumulative mtfix41 testing supports the fork release. Seven driver/wrapper/Table files and scoped local/server count-forwarding hunks match released mtfix41 source. This is not a new isolated Vouch test of upstream.

Local Linux GCC11 Debug normal and TLS: focused 7 cases/124 assertions each; wider normal 121 cases/91,766 assertions and TLS 122 cases/91,777 assertions, all passed. Counts overlap. Warnings-as-errors OFF; slow/flaky/stress name patterns excluded. No full uninterrupted CTest, fresh hosted cross-platform gates or Vouch validation of this port claimed.

Separate existing issue: an 80-row partially encrypted table with only row2 encrypted fails reopen5000 on unchanged upstream too (short bitmap). Not fixed here. Final count regression uses a complete bitmap and verifies count80 before/after reopen; it passes. See the private review note for the retained finding and build-interruption details.