I based my quick answer (see comments above) on

https://magma.maths.usyd.edu.au/magma/handbook/text/814

which states:

Cocycles Before invoking the functions in this section, it is necessary to first invoke the function CohomologyGroup(CM, n) for the appropriate n.

For n = 0, 1 or 2, an n-cocycle is a function from Gn to the module M, where elements of Gn are represented as an n-tuple < g1, ..., gn > of group elements, for which a certain relation is satisfied. These relations are consistent with the Magma convention of the use of right actions, and so they are slightly different from those encountered in many textbooks, where left actions are more common.

0-, 1- and 2-cocycles z, o and t, respectively, satisfy the following relations for all g, h, ∈G. z(< >)g = z(< >); o(< gh >) = o(< g >)h + o(< h >); t(< gh, k >) + t(< g, h >)k = t(< g, hk >) + t(< h, k >) .

However, I no longer think this is the problem. Adding the lines

z:Maximal; f:Maximal; CorestrictCocycle:Maximal;

to Jef's code gives the following output

function(gtp) ... end function function(X) ... end function Intrinsic 'CorestrictCocycle'

Signatures:

Defined in file: /magma/package/Ring/FldAb/ClassField5.m, line 234, column
5:
(G::Grp, C::ModCoho, c::UserProgram, i::RngIntElt) -> UserProgram

    The image of the cocyle c of the cohomology module C under the
    cohomological corestriction.

In particular, the code for the command "CorestrictCocycle" comes from the machinery relating to class field theory https://magma.maths.usyd.edu.au/magma/handbook/class_field_theory

and hence it may not match Derek Holts group cohomology code.

In fact I'm not sure that corestriction has been implemented in the generality Jef needs. Of course one can easily write some code to implement the transfer (cf. Mikhail Borovoi's answer); this will work if the index $[G:H]$ is small.

I based my quick answer (see comments above) on

https://magma.maths.usyd.edu.au/magma/handbook/text/814

which states:

Cocycles Before invoking the functions in this section, it is necessary to first invoke the function CohomologyGroup(CM, n) for the appropriate n.

For n = 0, 1 or 2, an n-cocycle is a function from Gn to the module M, where elements of Gn are represented as an n-tuple < g1, ..., gn > of group elements, for which a certain relation is satisfied. These relations are consistent with the Magma convention of the use of right actions, and so they are slightly different from those encountered in many textbooks, where left actions are more common.

0-, 1- and 2-cocycles z, o and t, respectively, satisfy the following relations for all g, h, ∈G. z(< >)g = z(< >); o(< gh >) = o(< g >)h + o(< h >); t(< gh, k >) + t(< g, h >)k = t(< g, hk >) + t(< h, k >) .

However, I no longer think this is the problem. Adding the lines

z:Maximal; f:Maximal; CorestrictCocycle:Maximal;

to Jef's code gives the following output

function(gtp) ... end function function(X) ... end function Intrinsic 'CorestrictCocycle'

Signatures:

Defined in file: /magma/package/Ring/FldAb/ClassField5.m, line 234, column
5:
(G::Grp, C::ModCoho, c::UserProgram, i::RngIntElt) -> UserProgram

    The image of the cocyle c of the cohomology module C under the
    cohomological corestriction.

In particular, the code for the command "CorestrictCocycle" comes from the machinery relating to class field theory https://magma.maths.usyd.edu.au/magma/handbook/class_field_theory

and hence it may not match Derek Holt's group cohomology code.

In fact I'm not sure that corestriction has been implemented in the generality Jef needs. Of course one can easily write some code to implement the transfer (cf. Mikhail Borovoi's answer); this will work if the index $[G:H]$ is small.