tests: record AFP temporary directory handle smoke results

Record the runtime Linux smoke coverage for the WebSDK/NWAFP NCP 0x2222/35/11 AFP Alloc Temporary Directory Handle request.

The implementation already returned the AFP reply as a temporary NetWare directory handle plus the one-byte AFP access-rights field. The real server diagnostic, however, logs the wider internal NetWare effective-rights mask from nw_alloc_dir_handle(), which can report 0x1ff for a privileged directory while the client-visible AFP field prints as 0xff. Document that distinction so the README matches the tested server log instead of implying a logging or protocol mismatch.

Also widen the diagnostic printf field width to 0x%03x to make the 9-bit NetWare rights mask intentional in future logs. This is only a diagnostic formatting change; the wire reply remains the AFP byte-sized rights field used by the smoke helper.

Tests:

- Runtime smoke reported green for SYS:, SYS:PUBLIC, SYS:SYSTEM, and SYS:BURST

- git diff --check

TODO:

- Entry-ID-only temporary handle allocation still waits for persistent CNID/base-ID lookup.

TODO.md

@@ -219,10 +219,14 @@ Current status:
   returning volume 0, `fork=0`, and stat-derived fallback Entry IDs for now.
 - `AFP Alloc Temporary Directory Handle` is implemented for the same
   path-backed smoke subset.  Linux smoke coverage exists in
-  `tests/linux/afp_temp_dir_handle_smoke`; it returns a temporary NetWare
-  directory handle plus effective-rights mask and immediately deallocates the
-  handle in the same connection.  Entry-ID-only allocation remains TODO until
-  persistent CNID/base-ID lookup exists.
+  `tests/linux/afp_temp_dir_handle_smoke`; runtime smoke coverage is green for
+  `SYS:`, `SYS:PUBLIC`, `SYS:SYSTEM`, and `SYS:BURST`.  The helper returns a
+  temporary NetWare directory handle plus the AFP one-byte access-rights mask
+  and immediately deallocates the handle in the same connection.  Server
+  diagnostics log the wider internal NetWare effective-rights mask, so
+  privileged directories can show `rights=0x1ff` while the client prints
+  `rights=0xff`.  Entry-ID-only allocation remains TODO until persistent
+  CNID/base-ID lookup exists.
 - The AFP dispatcher now decodes the WebSDK/NWAFP subfunction number in
   diagnostics so real client probes can be mapped to the corresponding AFP
   call before implementation work starts.

src/nwconn.c

@@ -666,7 +666,7 @@ static int afp_alloc_temporary_dir_handle(uint8 *afp_req, int afp_len,
   response[0] = (uint8)dirhandle;
   response[1] = (uint8)eff_rights;
 
-  XDPRINTF((3,0, "AFP Alloc Temporary Dir Handle: vol=%d entry=0x%08x path='%s' dir_handle=%d rights=0x%02x",
+  XDPRINTF((3,0, "AFP Alloc Temporary Dir Handle: vol=%d entry=0x%08x path='%s' dir_handle=%d rights=0x%03x",
             (int)volume_number, request_entry_id,
             visable_data(afp_req + 7, path_len), dirhandle, eff_rights));
   return(2);

tests/linux/README.md

@@ -167,13 +167,24 @@ deallocates the handle with the normal NetWare Deallocate Directory Handle call
 before closing the connection, so the handle value is only useful inside that
 client connection and must not be copied into later tests or server logs.
 
-Example output and server diagnostic shape:
+Runtime-verified output and server diagnostic shape:
 
 ```text
+AFP Alloc Temporary Dir Handle path=SYS: dir_handle=2 rights=0xff
 AFP Alloc Temporary Dir Handle path=SYS:PUBLIC dir_handle=2 rights=0xff
-AFP Alloc Temporary Dir Handle: vol=0 entry=0x00000000 path='SYS:PUBLIC' dir_handle=2 rights=0xff
+AFP Alloc Temporary Dir Handle path=SYS:SYSTEM dir_handle=2 rights=0xff
+AFP Alloc Temporary Dir Handle path=SYS:BURST dir_handle=2 rights=0xff
+AFP Alloc Temporary Dir Handle: vol=0 entry=0x00000000 path='SYS:' dir_handle=2 rights=0x1ff
+AFP Alloc Temporary Dir Handle: vol=0 entry=0x00000000 path='SYS:PUBLIC' dir_handle=2 rights=0x1ff
+AFP Alloc Temporary Dir Handle: vol=0 entry=0x00000000 path='SYS:SYSTEM' dir_handle=2 rights=0x1ff
+AFP Alloc Temporary Dir Handle: vol=0 entry=0x00000000 path='SYS:BURST' dir_handle=2 rights=0x1ff
 ```
 
+The AFP reply carries the one-byte access-rights field consumed by the smoke
+helper, so the client prints `0xff`.  The server diagnostic logs the internal
+NetWare effective-rights mask before that AFP reply narrowing, so a fully
+privileged directory can appear as `0x1ff` in `mars_nwe.log`.
+
 If the server was built without the optional Netatalk/libatalk backend, use
 `--allow-invalid-namespace` for the expected negative test.  Use
 `--allow-invalid-path` for path-resolution negative tests.