Refuse unknown [permissions].allow names and correct the Log / --profile critical docs

[O6lvl4]

Closes #3247
Closes #3249

Both fixes hold under any outcome of the effect-category redesign (#3243 / #3244). Nothing from those drafts is implemented here. ADR-0027 item 3 also says "unknown names are errors", which matches this change.

#3247: unknown [permissions].allow names are refused

• One matcher. Effect::ALL and Effect::from_name (crates/almide-ir/src/effect.rs) now define the vocabulary. project::allowed_effects is the only matcher, and both former copies (src/cli/mod.rs, src/cli/check.rs) now call it. It returns an error for an unknown name and never drops one.
• Located refusal before any command runs. The main manifest gate for A duplicate dependency key in almide.toml is accepted, then written into almide.lock twice, and the next run refuses the lock #2583 was refuse_duplicate_manifest_keys. It is now refuse_invalid_manifest, and it also runs project::check_manifest_permissions. That function reads the lines exactly as parse_toml does. The gate is needed because most manifest readers use parse_toml(..).ok(), so an error raised only inside the parser would quietly turn into "no permissions":

  error: almide.toml:6: unknown capability `Fil` in [permissions].allow — grantable capabilities are IO, Net, Env, Time, Rand, Fan
    hint: did you mean `IO`?
  

• Same wording on both paths. project::unknown_capability_message now also produces the --profile critical --allow refusal. That refusal gains the did-you-mean, which Unknown names in [permissions].allow are dropped silently, while --profile critical --allow rejects them #3247 asked for on both paths. A case-only miss (io) is suggested ahead of an edit-distance match. The two vocabularies stay as they are (Fan in the manifest, Process in --allow). Each message lists its own vocabulary.
• Diagnostic code: none. No manifest error carries a code today. The A duplicate dependency key in almide.toml is accepted, then written into almide.lock twice, and the next run refuses the lock #2583 duplicate-key refusal does not, and neither does the critical --allow refusal. This one follows them and prints path:line: with a hint. codes.toml, explain and the code-coverage floor are unchanged.

Tests:

• tests/diagnostics/permissions-unknown-capability/ is a broken/fixed pair. The harness gains broken.toml / fixed.toml: a case whose defect is in the manifest is staged in a scratch project with that file as almide.toml.
• tests/manifest_permissions_test.rs checks four things:
  • check, check --effects, build and run all refuse an unknown name on its line.
  • Log is refused.
  • Negative control: all six valid names pass, and a valid but narrow manifest still gets the usual capability violation.
  • The critical --allow path gives the suggestion.

#3249: docs say what the code does

• docs/specs/effect-system.md §8:
  • The Log row is gone. The table lists six categories and matches module_to_effect.
  • Time maps to datetime (time is not a module).
  • Rand now reads "no module infers it". Measured: random.int under allow = ["IO"] checks and builds.
  • The text states that io and random infer nothing.
  • The example manifest no longer uses Log.
  • A new "Unknown names" subsection is added.
  • §2.1 no longer mentions a log module (none exists).
• docs/specs/cli.md gains #### --profile critical. It is written from almide check --help and a probe, and covers:
  • the bounded profile on every function (E074)
  • deny-all capabilities (E076)
  • the --allow table from CAPABILITY_GRANTS
  • why Fan is absent
  • the four refusals
  • --json behaviour
• docs/diagnostics/E085.md now links that section instead of a section that did not exist.
• docs/roadmap/PRODUCTION_READY.md: Log removed from the category list.
• docs/wasm/capability-system.md: a note that its dotted names (FS.read, …) are a design, and the compiler refuses them.
• CHEATSHEET.md / llms.txt have no Log references. docs/adr/0022 (D1) and docs/roadmap/done/ still mention log. They are records and were not edited.

Gates run locally

• diagnostic_harness_test, manifest_permissions_test, critical_profile_test, manifest_duplicate_key_test, diagnostic_coverage_test, explain_list_test, explain_docs_test, diagnostic_silent_test: all green.
• check-contracts.sh, check-env-switches.sh, check-llm-surface.sh, check-diagnostic-code-coverage.sh: all green.
• Relative links and anchors in the five touched docs: 0 broken.
• codopsy HEAD (85ac6cd):
  • almide-ir: A 93, unchanged
  • almide-codegen: A 90, unchanged
  • root src: B 86, unchanged
• No ledger drifted.

Rebased onto #3235

#3235 added [permissions] proc. Both features are kept:

• check_proc_allowlist and enforce_proc_allowlist sit next to allowed_permissions_or_report in src/cli/mod.rs.
• The name gate judges only allow. A proc list holds commands, not capabilities, so the gate does not check it. tests/manifest_permissions_test.rs pins this.
• In docs/wasm/capability-system.md, Serve process on wasm through the private almide:process/spawn capability (ADR-0025) #3235's section "What the checker enforces today" is unchanged. The dotted-names note now points to it as the one implemented addition.

Not done here

A multi-line allow = [ array is still read as empty, which means "everything allowed". The line-based reader only handles a one-line array. This is outside #3247, so it is left for a follow-up.