fix(sync): Update jsonl_file_hash in finalizeExport to prevent spurious warnings (#1113)

The JSONL file hash mismatch warning was appearing consistently after
git commit operations, even when no actual data inconsistency existed.

Root Cause:
Two code paths export to JSONL but only one updated jsonl_file_hash:
- flushToJSONLWithState() (used by bd update/create): Updated both
  jsonl_content_hash AND jsonl_file_hash
- finalizeExport() (used by bd sync --flush-only): Updated only
  jsonl_content_hash, NOT jsonl_file_hash

Since validateJSONLIntegrity() checks jsonl_file_hash, any bd command
after a git commit would see a mismatch and trigger the warning.

Steps to Reproduce (before fix):
1. cd /path/to/beads-project
2. bd update -p 3 some-issue-id  # Works fine, stores hash H1
3. git add .beads/issues.jsonl && git commit --amend --no-edit
   # Pre-commit hook runs bd sync --flush-only
   # This updates jsonl_content_hash to H2 but leaves jsonl_file_hash as H1
4. bd update -p 3 some-issue-id  # WARNING appears!
   # validateJSONLIntegrity() compares file (H2) with jsonl_file_hash (H1)
5. Repeat steps 3-4 indefinitely - warning always appears

The fix adds SetJSONLFileHash() call to finalizeExport(), ensuring both
export paths update the same metadata consistently.

cmd/bd/sync_export.go

@@ -69,6 +69,12 @@ func finalizeExport(ctx context.Context, result *ExportResult) {
 			// is unavailable. This ensures export operations always succeed even if metadata storage fails.
 			fmt.Fprintf(os.Stderr, "Warning: failed to update jsonl_content_hash: %v\n", err)
 		}
+		// Also update jsonl_file_hash for integrity validation (bd-160)
+		// This ensures validateJSONLIntegrity() won't see a hash mismatch after
+		// bd sync --flush-only runs (e.g., from pre-commit hook).
+		if err := store.SetJSONLFileHash(ctx, result.ContentHash); err != nil {
+			fmt.Fprintf(os.Stderr, "Warning: failed to update jsonl_file_hash: %v\n", err)
+		}
 	}
 
 	// Update last_import_time