TL;DR No, "determinant" and "candidate key" are not the same concept. A determinant is of a FD. A CK is of a table. We can also reasonably say sloppily that a CK is a determinant (of a FD) of its table since it determines every column & column set in it.
All the following terms/concepts are defined in parallel for table values and variables. A table variable has an instance of a FD (functional dependency), determinant, superkey, CK (candidate key) or PK (primary key) (in the variable sense) when every table value that can arise for it in the given business/application has that instance (in the table sense).
For sets of columns X and Y we can write X -> Y. We say that X is the determinant/determining set and Y is the determined set of/in functional dependency (FD) X -> Y.
We say X functionally determines Y and Y is functionally determined by X. We say X is the determinant of X -> Y. In {C} -> Y we say C functionally determines Y. In X -> {C} we say X functionally determines C. When X is a superset of Y we say X -> Y is trivial.
We say X -> Y holds in table T when each subrow value for X only appears with the one particular subrow value for Y. Or we say X -> Y is a FD of/in T. When X is a determinant of some FD in table T we say X is a determinant of/in T. Every trivial FD of a table holds in it.
A superkey of a table T is a set of columns that functionally determines every column. A candidate key (CK) is a superkey that contains no smaller superkey. We can pick one CK as primary key (PK) and then call the other CKs alternate keys (AKs). A column is prime when it is in some CK.
Note that a determinant can be of a FD or, sloppily, of (a FD that holds in) a table. Every CK is a determinant of its table. (But then, in a table every set of columns is a determinant: of itself, trivially. And similarly every column.)
(These definitions do not depend on normalization. FDs and CKs of a table are used in normalizing it. A table is in BCNF when every determinant of a non-trivial FD that holds in it is a superkey.)
SQL tables are not relations and SQL operators are not their relational/mathematical counterparts. Among other things, SQL has duplicate rows, nulls & a kind of 3-valued logic. But although you can borrow terms and give them SQL meanings, you can't just substitute those meanings into other RM definitions or theorems and get something sensible or true. So we must convert an SQL design to a relational design, apply relational notions, then convert back to SQL. There are special cases where we can do certain things directly in SQL because we know what would happen if we did convert, apply & convert back.
