Decide whether imports should be split by PIE-derived destiny shares (dead code removed in #521)

Split out of #521, which removed the code described here as dead. Filing so the intent is not lost — the deletion was correct engineering, but it may have erased an unfinished plan.

What was removed

.finalize_prod_destiny() in R/n_prov_destiny.R contained a ~60-line block that
computed, per year and item, the share of imported N going to Food /
Other_uses / Feed, derived from the pie_full_destinies_fm pin and converted
FM→DM→N with biomass_coefs:

pie_imports_n <- whep_read_file("pie_full_destinies_fm") |>
  dplyr::filter(Element == "Import", Destiny %in% c("Food", "Other_uses", "Feed")) |>
  ...
  dplyr::mutate(share = dplyr::if_else(total > 0, value_n / total, 0))

shares_import_wide <- pie_imports_n |>
  tidyr::pivot_wider(names_from = Destiny, values_from = share, names_prefix = "share_")

shares_import_wide was passed to .split_import_consumption() as a third
argument that the function body never referenced. It was introduced already
unused (git log -S shares_import_wide → one commit, 6e98f4fd "Updates from
grafs_plot changes"), was undocumented in the helper roxygen, and an existing
passing test already called the helper with only two arguments. So it never
affected any output. Recoverable from 6e98f4fd.

The open question

.split_import_consumption() currently splits imports by the local demand
gap — the shortfall of each destiny after local production is allocated:

food_gap  <- pmax(food - food_local, 0)
...
share_food <- if_else(total_gap > 0, food_gap / total_gap, 0)

The deleted block would instead have split imports by what the PIE table says
imports were actually used for. These are different methods and give different
numbers:

• Demand-gap (current): assumes imports fill each destiny in proportion to
  what local production failed to cover. Self-consistent with the balance, but it
  cannot know that (say) imported maize goes overwhelmingly to feed while
  domestic maize goes to food.
• PIE-derived shares: uses the reported import destiny split directly, so
  imports of an item can have a different food/feed/other mix than domestic
  supply of the same item. Closer to the source data, but it can conflict with
  the demand gap and so needs a reconciliation rule when the two disagree.

Whether imports should carry their own destiny mix is a methodological choice
about the Spanish GRAFS provincial model, not a code cleanup, which is why it
is filed separately rather than resolved in a CI fix.

What is needed

• @eduaguilera (or whoever wrote 6e98f4fd) to say whether the PIE-derived split
  was the intended direction or an abandoned experiment.
• If intended: decide the reconciliation rule when PIE shares and the demand gap
  disagree, then re-add with a test and a before/after magnitude on
  create_n_prov_destiny().
• If abandoned: close this issue. Nothing further is needed; the code is already
  gone.

Related: #490 / #521 (why it surfaced), #489 (biomass_coefs, which the deleted
block also read).

Read R/n_prov_destiny.R, especially .split_import_consumption() and .finalize_prod_destiny(), then inspect commit 6e98f4fd and the existing helper test. First establish whether PIE-derived import shares were intended or abandoned. Done means documenting that decision; if intended, agree on a reconciliation rule, add a test, and compare create_n_prov_destiny() magnitudes before and after.