Command-line `-F` then `-A` lint-level flags behave inconsistently versus in-source `#[forbid(..)]` then `#[allow(..)]` lint-level attributes

[jieyouxu]

For a given program

#![crate_type = "lib"]
fn foo() {}

Currently (rustc 1.82.0), rustc -F unused -A unused will produce

error: function `foo` is never used
 --> .\bar.rs:1:4
  |
1 | fn foo() {}
  |    ^^^
  |
  = note: `-F dead-code` implied by `-F unused`

error: aborting due to 1 previous error

However, switching to source lint level attributes

#![forbid(unused)]
#![allow(unused)]
#![crate_type = "lib"]
fn foo() {}

will instead produce

warning: allow(unused) incompatible with previous forbid
 --> .\foo.rs:2:10
  |
1 | #![forbid(unused)]
  |           ------ `forbid` level set here
2 | #![allow(unused)]
  |          ^^^^^^ overruled by previous forbid
  |
  = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
  = note: for more information, see issue #81670 <https://github.com/rust-lang/rust/issues/81670>
  = note: `#[warn(forbidden_lint_groups)]` on by default

warning: 1 warning emitted

According to my understanding, the purpose of -F/forbid for lints is that they can not be allowed any more. Thus I would expect that calling rustc with -Funused -Aunused will fail when there is unused code in the file.
-- #70819 (comment)

This was changed in #67885.

---

Original issue reported by @RalfJung, this issue is extracted out of #70819 to focus on the difference between rustc cli lint level flags (e.g. -F../-A..) versus source lint level attributes (e.g. #[forbid(..)]/#[allow(..)]).

cc @RalfJung could you double-check if my transcription is accurate of what you find surprising/undesirable?

[jieyouxu]

(Tagging as C-discussion status to determine if this is "intended behavior" or "bug" for now.)