[0fk]'s section weight comes from the release lane; the ASan shards now build its ASan flavour: re-measure #1790

Follow-up of #1784, which #1776 closes (commit d8076836 on phase2-numbers).

tests/section_weights.txt was refreshed from the ASan shard logs of run 38652383231 (head 6fe6f0a). [0fk], the #1758 C slot test, was not in that run, so its row (53.33 s) was taken from #1776's linux / gcc lane. That lane runs the release flavour of the slot test, compiled at -O2.

The same commit changed what [0fk] costs in the ASan shards:

• Before, [0fk] detected only build/asan, so the shards (which build asan-server) compiled the release flavour ([0ff] and [0fk] pick their ASan variant only for build/asan; the CI ASan shards build asan-server, so both run as release there #1783).
• Now the shared predicate picks the ASan flavour there: the amalgamation compiled with ASan/UBSan at -O1 plus -Wall -Wextra.
• On the 4 GB dev box that build and run took 284 s at a 1.7 GB peak RSS, against 45.7 s for the release flavour (now -O0). CI is faster per core, but the 53.33 s row likely understates the shard cost, and the planner balances the three ASan shards on these weights.

Done when

• tests/section_weights.txt is refreshed from the shard logs of one CI ASan run whose head contains d8076836, using the recipe in the file's header. The [0fk] row is then that run's measured SECTION_TIME, and the header's note about the borrowed row is removed.
• bash tools/section_plan.sh --shards 3 --check prints unmeasured-sections=0 at that head.