m alora upload's default layout is incompatible with add-readme's generated usage code #1620

Problem

m alora add-readme always generates usage code that loads the trained
adapter via LocalFileBinding (or, before #1144, the deprecated
IntrinsicAdapter/CustomIntrinsicAdapter shims) — which only finds weights
at <name>/<base-model>/<lora|alora>/ inside the Hugging Face repo (see
adapter_subpath() in mellea/formatters/granite/intrinsics/util.py). But
m alora upload defaults to --intrinsic=False, which pushes weights flat
to the repo root instead (cli/alora/upload.py, path_in_repo=".").

A user following the CLI in the "obvious" order — train → upload →
add-readme (or add-readme → upload) — gets a broken pairing by default:
the generated README's own code fails with

ValueError: Intrinsic '<name>' as aLoRA adapter on base model '<base-model>'
not found in <repo> repository on Hugging Face Hub. Searched for path
<name>/<base-model>/alora/*

The fix already exists and works — m alora upload ... --intrinsic --io-yaml ./io.yaml pushes into the correct nested layout (upload_intrinsic() in
cli/alora/intrinsic_uploader.py) — but nothing in the CLI's own flow
surfaces that requirement until the user hits this error.

Reproducer

m alora train ./data.jsonl --base-model ibm-granite/granite-4.1-3b --output ./adapter
m alora upload ./adapter --name your-org/my-adapter   # no --intrinsic
m alora add-readme ./adapter --name your-org/my-adapter --dataset ./data.jsonl

Then run the generated INTRINSIC_README.md's own example code — it raises
the ValueError above.

Expected behavior

Some combination of:

• add-readme detects (or is told) whether the target repo actually has the
  intrinsic-style layout, and warns/refuses if not, rather than generating
  code that's guaranteed to fail.
• upload makes the intrinsic path harder to miss — e.g. a clearer error
  when add-readme's generated usage pattern won't work against a flat
  upload, or defaulting --intrinsic to True (a breaking CLI change,
  needs its own deprecation consideration — plain, non-intrinsic adapter
  publishing via m alora upload with no flags is also a legitimate,
  intentional use case, so this isn't a clear-cut default flip).

Filed as needs-design rather than proposing a specific fix — the right
tradeoff between the two workflows (plain PEFT publishing vs.
intrinsic/adapter-function publishing) needs discussion before implementation.

Context

Found while verifying
#1619 (part of
#1144)'s new "Adding a custom adapter function" tutorial end-to-end against
real hardware. That PR adds an explicit caveat to the tutorial and to the
CLI-generated README template pointing at --intrinsic --io-yaml as a
stopgap, but the underlying CLI ergonomics gap is unrelated to the
shim-vs-composed-Adapter change #1619 makes, and predates it — the
deprecated IntrinsicAdapter/CustomIntrinsicAdapter shims have the exact
same layout requirement, so this isn't a regression from that work.